Re: Data corruption issue with splice() on 2.6.27.10

[Evgeniy Polyakov <zbr@ioremap.net>]

On Wed, Jan 07, 2009 at 11:57:34PM +1100, Herbert Xu (herbert@gondor.apana.org.au) wrote:
> On Wed, Jan 07, 2009 at 01:55:35PM +0100, Willy Tarreau wrote:
> > 
> > kernel is 2.6.27.10 + a few patches (squashfs, etc..., nothing related to
> 
> 2.6.27 will enable GSO by default if SG is enabled at registration
> time.

So even if later sg was turned off without gso being turned off, it
will try doing fair page transfer and not falling back to the copy.

The simplest case is to also turn gso off, but with older ethtools it is
not possible and you hit the bug.

If I understood correctly Jarek's patch, he wants to allocate a page and
copy linear content of the skb there, so this will end up being the same
case as with splicing from the file. And while generally this may be a
good idea, but with usual 1.5k mtu this will copy every skb, which is
rather bad idea. Will have to think :)

-- 
	Evgeniy Polyakov