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]
Date:	Wed, 17 Dec 2008 10:15:34 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Herbert Xu <herbert@...dor.apana.org.au>
cc:	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>, ptesarik@...e.cz
Subject: Re: [PATCH] tcp: make urg+gso work for real this time

On Wed, 17 Dec 2008, Herbert Xu wrote:

> Ilpo J??rvinen <ilpo.jarvinen@...sinki.fi> wrote:
> > 
> > I should have noticed this earlier... :-) The previous solution
> > to URG+GSO/TSO will cause SACK block tcp_fragment to do zig-zig
> > patterns, or even worse, a steep downward slope into packet
> > counting because each skb pcount would be truncated to pcount
> > of 2 and then the following fragments of the later portion would
> > restore the window again.
> 
> How about just handling it, URG isn't that hard.  If anyone is
> bored you can do this for GRO as well.
>
> tcp: Add GSO support for urgent data
> 
> When segmenting packets with urgent data we need to clear the
> urgent flag/pointer once we move past the end of the urgent data.
> This was not handled correctly in GSO or (presumably) in existing
> hardware.
>
> This patch adds a new GSO flag for TCP urgent data and also fixes
> its handling in GSO.
> 
> Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>

This is certainly nice and possible but as mention earlier, the harder 
problem is that the urg_ptr is only 16-bits so there will be still be 
problem if the urgent seq-64k mark is within a super-skb as tail segments 
need urg while the head ones won't. I think we would need out-of-band 
means to communicate the extra bit (17th) from tcp if we want to solve 
that one. It would be rather easy to change TCP to only do splitting for 
that particular skb though and keep everything else intact.

...The same consideration applies to gro as well.


-- 
 i.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ