[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20190816.162737.128286385440292449.davem@davemloft.net>
Date: Fri, 16 Aug 2019 16:27:37 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: tuong.t.lien@...tech.com.au
Cc: jon.maloy@...csson.com, maloy@...jonn.com, ying.xue@...driver.com,
netdev@...r.kernel.org, tipc-discussion@...ts.sourceforge.net
Subject: Re: [net] tipc: fix false detection of retransmit failures
From: Tuong Lien <tuong.t.lien@...tech.com.au>
Date: Thu, 15 Aug 2019 10:24:08 +0700
> This commit eliminates the use of the link 'stale_limit' & 'prev_from'
> (besides the already removed - 'stale_cnt') variables in the detection
> of repeated retransmit failures as there is no proper way to initialize
> them to avoid a false detection, i.e. it is not really a retransmission
> failure but due to a garbage values in the variables.
>
> Instead, a jiffies variable will be added to individual skbs (like the
> way we restrict the skb retransmissions) in order to mark the first skb
> retransmit time. Later on, at the next retransmissions, the timestamp
> will be checked to see if the skb in the link transmq is "too stale",
> that is, the link tolerance time has passed, so that a link reset will
> be ordered. Note, just checking on the first skb in the queue is fine
> enough since it must be the oldest one.
> A counter is also added to keep track the actual skb retransmissions'
> number for later checking when the failure happens.
>
> The downside of this approach is that the skb->cb[] buffer is about to
> be exhausted, however it is always able to allocate another memory area
> and keep a reference to it when needed.
>
> Fixes: 77cf8edbc0e7 ("tipc: simplify stale link failure criteria")
> Reported-by: Hoang Le <hoang.h.le@...tech.com.au>
> Acked-by: Ying Xue <ying.xue@...driver.com>
> Acked-by: Jon Maloy <jon.maloy@...csson.com>
> Signed-off-by: Tuong Lien <tuong.t.lien@...tech.com.au>
Applied, thank you.
Powered by blists - more mailing lists