Patchwork [net] tipc: fix link established but not in session

login
register
mail settings
Submitter Tuong Lien
Date April 16, 2019, 3:48 a.m.
Message ID <20190416034807.20460-1-tuong.t.lien@dektech.com.au>
Download mbox | patch
Permalink /patch/773873/
State New
Headers show

Comments

Tuong Lien - April 16, 2019, 3:48 a.m.
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(+)
David Miller - April 17, 2019, 4:32 a.m.
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.

Patch

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;