From patchwork Fri May 9 13:13:24 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jon Maloy X-Patchwork-Id: 347413 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id BCD0C140122 for ; Fri, 9 May 2014 23:21:22 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754431AbaEINUt (ORCPT ); Fri, 9 May 2014 09:20:49 -0400 Received: from smtp105.biz.mail.ne1.yahoo.com ([98.138.207.12]:37140 "HELO smtp105.biz.mail.ne1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751270AbaEINUr (ORCPT ); Fri, 9 May 2014 09:20:47 -0400 Received: (qmail 95365 invoked from network); 9 May 2014 13:14:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1399641247; bh=iI7L+kEABTy1n9RWmJWur9pyrJPVemgA70U7/tqfO5o=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References; b=ExCoJwa1kSEB7JNULfl/2Fgu9MDM9xUBgpmn9zOwrIQ88cPRN7IRAX1scFV/SbMFwiVtXRBlp+kHCiHzB6Ns8KtZ+IHYIRLwvuBWufdXhCWyGwTY4rgcgCTfQuWc9EgF6Axwxh/W1R3kqLiG+1Xt4YdvVX/mCX2vIiTbZsrx8Vs= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 2FKe8y0VM1kgOyJXyIxaDRhQK8XqTT6rhemtZ4sddvgXkB4 I0f.88xTOF0IiiRxYnbSI17wnSkEgQbATr6Rix8dIQxGc2WGcVFufgh9yTJ0 ipjO8hj4pkp8NH_rjLeWXwlV876sW68EedbGwa90Sc24aQRqaLoybFj7i0C4 o6_wUpVo9AX3uQY5LWUGM.DRDSe8jK8Q_HjAnw0ZTJegI_r1Z0JQ82TLLE2s gb0lbNPK8A9PPPXKQaxJwS2QKCpqzciiRhWki9z3cy4_hBCNQk70KPZHIaWZ JPiOx8bJJGuwCWuUgyXPm4_qilJAzFTvgPTrbF.Pnr4TI4u6huFlBkn_ueBX D3F1cqFsR8c9uhl.tXh8gGbbGSlGRyyE7b8E29f.JH_bkfaQ8qL5WVy_b0lD VE5AZwOKZrXmPpTm0tQ.EnmtmSBAMBMkmBRqrwKzmlje_d1xyED6sVzcgIsZ wI5oCIUWNFo5JBPysxWThBNJYF4Cz6ZsIx7yydReVhztLYR6ZIC1wNKH9OeJ qGPAe4UjN3qbVHPL6w1zikdzaeOQYaA-- X-Yahoo-SMTP: gPXIZm2swBAFQJ_Vx0CebjUfUdhJ X-Rocket-Received: from goethe.lan (jon.maloy@65.93.115.57 with plain [98.138.105.25]) by smtp105.biz.mail.ne1.yahoo.com with SMTP; 09 May 2014 06:14:06 -0700 PDT From: Jon Maloy To: davem@davemloft.net Cc: netdev@vger.kernel.org, Paul Gortmaker , erik.hugne@ericsson.com, ying.xue@windriver.com, maloy@donjonn.com, tipc-discussion@lists.sourceforge.net, Jon Maloy Subject: [PATCH net-next 3/8] tipc: don't record link RESET or ACTIVATE messages as traffic Date: Fri, 9 May 2014 09:13:24 -0400 Message-Id: <1399641209-26112-4-git-send-email-jon.maloy@ericsson.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1399641209-26112-1-git-send-email-jon.maloy@ericsson.com> References: <1399641209-26112-1-git-send-email-jon.maloy@ericsson.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org In the current code, all incoming LINK_PROTOCOL messages, irrespective of type, nudge the "last message received" checkpoint, informing the link state machine that a message was received from the peer since last supervision timeout event. This inhibits the link from starting probing the peer unnecessarily. However, not only STATE messages are recorded as legitimate incoming traffic this way, but even RESET and ACTIVATE messages, which in reality are there to inform the link that the peer endpoint has been reset. At the same time, some RESET messages may be dropped instead of causing a link reset. This happens when the link endpoint thinks it is fully up and working, and the session number of the RESET is lower than or equal to the current link session. In such cases the RESET is perceived as a delayed remnant from an earlier session, or the current one, and dropped. Now, if a TIPC module is removed and then immediately reinserted, e.g. when using a script, RESET messages may arrive at the peer link endpoint before this one has had time to discover the failure. The RESET may be dropped because of the session number, but only after it has been recorded as a legitimate traffic event. Hence, the receiving link will not start probing, and not discover that the peer endpoint is down, at the same time ignoring the periodic RESET messages coming from that endpoint. We have ended up in a stale state where a failed link cannot be re-established. In this commit, we remedy this by nudging the checkpoint only for received STATE messages, not for RESET or ACTIVATE messages. Signed-off-by: Jon Maloy Reviewed-by: Ying Xue --- net/tipc/link.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/net/tipc/link.c b/net/tipc/link.c index 2140837..6cf7938 100644 --- a/net/tipc/link.c +++ b/net/tipc/link.c @@ -1831,9 +1831,6 @@ static void tipc_link_proto_rcv(struct tipc_link *l_ptr, struct sk_buff *buf) if (l_ptr->exp_msg_count) goto exit; - /* record unnumbered packet arrival (force mismatch on next timeout) */ - l_ptr->checkpoint--; - if (l_ptr->net_plane != msg_net_plane(msg)) if (tipc_own_addr > msg_prevnode(msg)) l_ptr->net_plane = msg_net_plane(msg); @@ -1909,6 +1906,10 @@ static void tipc_link_proto_rcv(struct tipc_link *l_ptr, struct sk_buff *buf) tipc_link_reset(l_ptr); /* Enforce change to take effect */ break; } + + /* Record reception; force mismatch at next timeout: */ + l_ptr->checkpoint--; + link_state_event(l_ptr, TRAFFIC_MSG_EVT); l_ptr->stats.recv_states++; if (link_reset_unknown(l_ptr))