netdev - Re: SWS for rcvbuf

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: <200703051152.27780.alexandre.sidorenko@hp.com>
Date:	Mon, 5 Mar 2007 11:52:27 -0500
From:	Alex Sidorenko <alexandre.sidorenko@...com>
To:	John Heffner <jheffner@....edu>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: SWS for rcvbuf < MTU

On March 3, 2007 06:40:12 pm John Heffner wrote:
> David Miller wrote:
> > From: John Heffner <jheffner@....edu>
> > Date: Fri, 02 Mar 2007 16:16:39 -0500
> >
> >> Please don't apply the patch I sent.  I've been thinking about this a
> >> bit harder, and it may not fix this particular problem.  (Hard to say
> >> without knowing exactly what it is.)  As the comment above
> >> __tcp_select_window() states, we do not do full receive-side SWS
> >> avoidance because of header prediction.
> >>
> >> Alex, you're right I missed that special zero-window case.  I'm still
> >> not quite sure I'm completely happy with this patch.  I'd like to think
> >> about this a little bit harder...
> >
> > Ok
>
> Alright, I've thought about it a bit more, and I think the patch I sent
> should work.  Alex, any opinion?  Any way you can test this out?

Here are the values from live kernel (obtained with 'crash') when the host was 
in SWS state:

full_space=708		full_space/2=354
free_space=393
window=76

In this case the test from my original fix, (window < full_space/2),  
succeeds. But John's test

free_space > window + full_space/2
393          430

does not. So I suspect that the new fix will not always work. From tcpdump 
traces we can see that both hosts exchange with 76-byte packets for a long 
time. From customer's application log we see that it continues to read 
76-byte chunks per each read() call - even though more than that is available 
in the receive buffer. Technically it's OK for read() to return even after 
reading one byte, so if sk->receive_queue contains multiple 76-byte skbuffs 
we may return after processing just one skbuff (but we we don't understand 
the details of why this happens on customer's system).

Are there any particular reasons why you want to postpone window update until 
free_space becomes > window + full_space/2 and not as soon as 
free_space > full_space/2? As the only real-life occurance of SWS shows 
free_space oscillating slightly above full_space/2, I created the fix 
specifically to match this phenomena as seen on customer's host. We reach the 
modified section only when (free_space > full_space/2) so it should be OK to 
update the window at this point if mss==full_space. 

So yes, we can test John's fix on customer's host but I doubt it will work for 
the reasons mentioned above, in brief:

'window = free_space' instead of 'window=full_space/2' is OK,
but the test 'free_space > window + full_space/2' is not for the specific 
pattern customer sees on his hosts.

Thanks,
Alex

-- 
------------------------------------------------------------------
Alexandre Sidorenko             email: alexs@...inux.canada.hp.com
Global Solutions Engineering:   Unix Networking
Hewlett-Packard (Canada)
------------------------------------------------------------------
-
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