| Message ID | 20190416034807.20460-1-tuong.t.lien@dektech.com.au |
|---|---|
| State | Accepted |
| Delegated to: | David Miller |
| Headers | show |
| Series | [net] tipc: fix link established but not in session | expand |
From: Tuong Lien <tuong.t.lien@dektech.com.au> Date: Tue, 16 Apr 2019 10:48:07 +0700 > According to the link FSM, when a link endpoint got RESET_MSG (- a > traditional one without the stopping bit) from its peer, it moves to > PEER_RESET state and raises a LINK_DOWN event which then resets the > link itself. Its state will become ESTABLISHING after the reset event > and the link will be re-established soon after this endpoint starts to > send ACTIVATE_MSG to the peer. > > There is no problem with this mechanism, however the link resetting has > cleared the link 'in_session' flag (along with the other important link > data such as: the link 'mtu') that was correctly set up at the 1st step > (i.e. when this endpoint received the peer RESET_MSG). As a result, the > link will become ESTABLISHED, but the 'in_session' flag is not set, and > all STATE_MSG from its peer will be dropped at the link_validate_msg(). > It means the link not synced and will sooner or later face a failure. > > Since the link reset action is obviously needed for a new link session > (this is also true in the other situations), the problem here is that > the link is re-established a bit too early when the link endpoints are > not really in-sync yet. The commit forces a resync as already done in > the previous commit 91986ee166cf ("tipc: fix link session and > re-establish issues") by simply varying the link 'peer_session' value > at the link_reset(). > > Acked-by: Jon Maloy <jon.maloy@ericsson.com> > Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au> Applied.
diff --git a/net/tipc/link.c b/net/tipc/link.c index 3cb9f326ee6f..6053489c8063 100644 --- a/net/tipc/link.c +++ b/net/tipc/link.c @@ -876,6 +876,8 @@ void tipc_link_reset(struct tipc_link *l) __skb_queue_head_init(&list); l->in_session = false; + /* Force re-synch of peer session number before establishing */ + l->peer_session--; l->session++; l->mtu = l->advertised_mtu;
According to the link FSM, when a link endpoint got RESET_MSG (- a traditional one without the stopping bit) from its peer, it moves to PEER_RESET state and raises a LINK_DOWN event which then resets the link itself. Its state will become ESTABLISHING after the reset event and the link will be re-established soon after this endpoint starts to send ACTIVATE_MSG to the peer. There is no problem with this mechanism, however the link resetting has cleared the link 'in_session' flag (along with the other important link data such as: the link 'mtu') that was correctly set up at the 1st step (i.e. when this endpoint received the peer RESET_MSG). As a result, the link will become ESTABLISHED, but the 'in_session' flag is not set, and all STATE_MSG from its peer will be dropped at the link_validate_msg(). It means the link not synced and will sooner or later face a failure. Since the link reset action is obviously needed for a new link session (this is also true in the other situations), the problem here is that the link is re-established a bit too early when the link endpoints are not really in-sync yet. The commit forces a resync as already done in the previous commit 91986ee166cf ("tipc: fix link session and re-establish issues") by simply varying the link 'peer_session' value at the link_reset(). Acked-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au> --- net/tipc/link.c | 2 ++ 1 file changed, 2 insertions(+)