From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [net 1/1] tipc: fix problems with multipoint-to-point flow control Date: Tue, 02 Jan 2018 21:52:27 -0500 (EST) Message-ID: <20180102.215227.1836995198743909376.davem@davemloft.net> References: <1514573282-4355-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, mohan.krishna.ghanta.krishnamurthy@ericsson.com, tung.q.nguyen@dektech.com.au, hoang.h.le@dektech.com.au, canh.d.luu@dektech.com.au, ying.xue@windriver.com, tipc-discussion@lists.sourceforge.net To: jon.maloy@ericsson.com Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:55212 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751148AbeACCw3 (ORCPT ); Tue, 2 Jan 2018 21:52:29 -0500 In-Reply-To: <1514573282-4355-1-git-send-email-jon.maloy@ericsson.com> Sender: netdev-owner@vger.kernel.org List-ID: From: Jon Maloy Date: Fri, 29 Dec 2017 19:48:02 +0100 > In commit 04d7b574b245 ("tipc: add multipoint-to-point flow control") we > introduced a protocol for preventing buffer overflow when many group > members try to simultaneously send messages to the same receiving member. > > Stress test of this mechanism has revealed a couple of related bugs: > > - When the receiving member receives an advertisement REMIT message from > one of the senders, it will sometimes prematurely activate a pending > member and send it the remitted advertisement, although the upper > limit for active senders has been reached. This leads to accumulation > of illegal advertisements, and eventually to messages being dropped > because of receive buffer overflow. > > - When the receiving member leaves REMITTED state while a received > message is being read, we miss to look at the pending queue, to > activate the oldest pending peer. This leads to some pending senders > being starved out, and never getting the opportunity to profit from > the remitted advertisement. > > We fix the former in the function tipc_group_proto_rcv() by returning > directly from the function once it becomes clear that the remitting > peer cannot leave REMITTED state at that point. > > We fix the latter in the function tipc_group_update_rcv_win() by looking > up and activate the longest pending peer when it becomes clear that the > remitting peer now can leave REMITTED state. > > Signed-off-by: Jon Maloy Applied, thanks Jon.