From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [net 1/1] tipc: fix link re-establish failure Date: Sun, 11 Nov 2018 10:04:29 -0800 (PST) Message-ID: <20181111.100429.1719075671755879075.davem@davemloft.net> References: <1541889024-18110-1-git-send-email-jon.maloy@ericsson.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, gordan.mihaljevic@dektech.com.au, tung.q.nguyen@dektech.com.au, hoang.h.le@dektech.com.au, jon.maloy@ericsson.com, maloy@donjonn.com, xinl@redhat.com, ying.xue@windriver.com, tipc-discussion@lists.sourceforge.net To: donmalo99@gmail.com Return-path: Received: from shards.monkeyblade.net ([23.128.96.9]:37642 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729274AbeKLDxm (ORCPT ); Sun, 11 Nov 2018 22:53:42 -0500 In-Reply-To: <1541889024-18110-1-git-send-email-jon.maloy@ericsson.com> Sender: netdev-owner@vger.kernel.org List-ID: From: Jon Maloy Date: Sat, 10 Nov 2018 17:30:24 -0500 > When a link failure is detected locally, the link is reset, the flag > link->in_session is set to false, and a RESET_MSG with the 'stopping' > bit set is sent to the peer. > > The purpose of this bit is to inform the peer that this endpoint just > is going down, and that the peer should handle the reception of this > particular RESET message as a local failure. This forces the peer to > accept another RESET or ACTIVATE message from this endpoint before it > can re-establish the link. This again is necessary to ensure that > link session numbers are properly exchanged before the link comes up > again. > > If a failure is detected locally at the same time at the peer endpoint > this will do the same, which is also a correct behavior. > > However, when receiving such messages, the endpoints will not > distinguish between 'stopping' RESETs and ordinary ones when it comes > to updating session numbers. Both endpoints will copy the received > session number and set their 'in_session' flags to true at the > reception, while they are still expecting another RESET from the > peer before they can go ahead and re-establish. This is contradictory, > since, after applying the validation check referred to below, the > 'in_session' flag will cause rejection of all such messages, and the > link will never come up again. > > We now fix this by not only handling received RESET/STOPPING messages > as a local failure, but also by omitting to set a new session number > and the 'in_session' flag in such cases. > > Fixes: 7ea817f4e832 ("tipc: check session number before accepting link protocol messages") > Signed-off-by: Jon Maloy Applied and queued up for -stable.