diff options
author | Tuong Lien <tuong.t.lien@dektech.com.au> | 2019-04-16 06:48:07 +0300 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2019-04-17 07:31:26 +0300 |
commit | f7a937801b9f8788519a23b12cb4d6c2c84d84be (patch) | |
tree | b91be80f45617d17afef81664b8a72e8f873f878 /net/tipc/sysctl.c | |
parent | d85e8be2a5a02869f815dd0ac2d743deb4cd7957 (diff) | |
download | linux-f7a937801b9f8788519a23b12cb4d6c2c84d84be.tar.xz |
tipc: fix link established but not in session
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>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/tipc/sysctl.c')
0 files changed, 0 insertions, 0 deletions