netdev - Re: [PATCH net v2] sctp: start t5 timer only when peer.rwnd is 0 and local.state is SHUTDOWN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150824191325.GC1873@localhost.localdomain>
Date:	Mon, 24 Aug 2015 16:13:25 -0300
From:	Marcelo Ricardo Leitner <mleitner@...hat.com>
To:	Vlad Yasevich <vyasevic@...hat.com>
Cc:	Xin Long <lucien.xin@...il.com>,
	network dev <netdev@...r.kernel.org>, tgraf@...radead.org,
	davem@...emloft.net
Subject: Re: [PATCH net v2] sctp: start t5 timer only when peer.rwnd is 0 and
 local.state is SHUTDOWN_PENDING

On Mon, Aug 24, 2015 at 02:36:59PM -0400, Vlad Yasevich wrote:
> On 08/24/2015 02:31 PM, Marcelo Ricardo Leitner wrote:
> > On Mon, Aug 24, 2015 at 02:13:38PM -0400, Vlad Yasevich wrote:
> >> On 08/23/2015 07:30 AM, Xin Long wrote:
> >>> when A sends a data to B, then A close() and enter into SHUTDOWN_PENDING state,
> >>> if B neither claim his rwnd is 0 nor send SACK for this data, A will keep
> >>> retransmitting this data util t5 timeout, Max.Retrans times can't work anymore,
> >>> which is bad.
> >>>
> >>> if B's rwnd is not 0, it should send abord after Max.Retrans times, only when
> >>> B's rwnd == 0 and A's retransmitting beyonds Max.Retrans times, A will start
> >>> t5 timer, which is also commit f8d960524 means, but it lacks the condition
> >>> peer.rwnd == 0.
> >>>
> >>> Fixes: f8d960524 ("sctp: Enforce retransmission limit during shutdown")
> >>> Signed-off-by: Xin Long <lucien.xin@...il.com>
> >>> ---
> >>>  net/sctp/sm_statefuns.c | 3 ++-
> >>>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> >>> index 3ee27b7..deb9eab 100644
> >>> --- a/net/sctp/sm_statefuns.c
> >>> +++ b/net/sctp/sm_statefuns.c
> >>> @@ -5412,7 +5412,8 @@ sctp_disposition_t sctp_sf_do_6_3_3_rtx(struct net *net,
> >>>  	SCTP_INC_STATS(net, SCTP_MIB_T3_RTX_EXPIREDS);
> >>>  
> >>>  	if (asoc->overall_error_count >= asoc->max_retrans) {
> >>> -		if (asoc->state == SCTP_STATE_SHUTDOWN_PENDING) {
> >>> +		if (!q->asoc->peer.rwnd &&
> >>> +		    asoc->state == SCTP_STATE_SHUTDOWN_PENDING) {
> >>>  			/*
> >>>  			 * We are here likely because the receiver had its rwnd
> >>>  			 * closed for a while and we have not been able to
> >>>
> >>
> >> This may not work as expected.  peer.rwnd is the calculated peer window, but it
> >> also gets updated when we receive sacks.  So there is no way to tell that
> >> the current windows is 0 because peer told us, or because we sent data to make 0
> >> and the peer hasn't responded.
> > 
> > I'm not sure I follow you, Vlad. I don't think we care on why we have
> > zero-window in there, just that if we are at it on that stage. Either
> > one, if it's zero window, we will go through T5 and give it more time to
> > recover, but if it's not zero window, I don't see a reason to enable T5..
> 
> No, these are 2 distinct instances.  In one instance, the peer is reachable and
> is able to communication 0 rwnd state to us.  Thus we are being nice and granting
> the peer more time to exit the 0 window state.
> 
> In the other state, the peer is unreachable and we just happen to hit the 0-window
> condition based on some estimations of the peer window.  In this case, we should
> be subject to the Max.RTX and terminate the association sooner.

Makes sense, we can do better in there. Thanks Vlad.

  Marcelo

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html