On Wed, Jan 07, 2009 at 03:42:32PM +1100, Herbert Xu wrote:> On Tue, Jan 06, 2009 at 06:37:05PM +0000, Jens Axboe wrote:> > > > I'll give this a spin tomorrow as well. A hunch tells me that this is> > likely a page reuse issue, that splice is getting the reference to the> > buffer dropped before the data has really been transmitted. IOW, the> > page is likely fine reaching the ->sendpage() bit, but will be reused> > before the data has actually been transmitted. So once you get that far,> > other random data from that page is going out.> > I see the problem.> > The socket pipes in net/core/skbuff.c use references on the skb> to hold down the memory in skb->head as well as the pages in the> skb.> > Unfortunately, once the pipe is fed into sendpage we only use> page reference counting to pin down the memory. So as soon as> sendpage returns we drop the ref count on the skb, thus freeing> the memory in skb->head, which is yet to be transmitted.

So this means that anything relying on sendpage() is at risk ? WhatI find really strange is that I can only reproduce the issue if thespliced data come from a real interface. If they come from the loopbackor from a file, there is no problem. Maybe the ref counting is differentdepending on the origin of the data ?

> Moral: Using page reference counts on skb->head is wrong.

My question will sound stupid to some of you, but wouldn't increasingthe refcount on those skb solve the problem (and decreasing it oncethe skb is effectively sent) ?