[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090107123741.GA31255@ioremap.net>
Date: Wed, 7 Jan 2009 15:37:41 +0300
From: Evgeniy Polyakov <zbr@...emap.net>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Jens Axboe <jens.axboe@...cle.com>, Willy Tarreau <w@....eu>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Data corruption issue with splice() on 2.6.27.10
On Wed, Jan 07, 2009 at 11:22:38PM +1100, Herbert Xu (herbert@...dor.apana.org.au) wrote:
> > Looks like we are talking about different directions of the dataflow.
> > I meant that set of pages submitted into the sending part will be copied
> > if sending interface does not support acceleration, and thus it will
> > copy part of the page corresponding to the linear part of the skb prior
> > the transmission, so even if skb will be freed right after that call
> > (prior data transmission by the hardware), it should not affect copied
> > data.
>
> You must be looking at a different tcp.c than the one I've got
> because mine clearly always uses skb frags in sendpage regardless
> of SG support.
Doesn't your tcp fallbacks to kernel_sendmsg() without sg in
tcp_sendpage()? And then just feeds data into the stack the same way it
happens with send() i.e. by copying it.
> Yes we will linearize the packet in dev_queue_xmit but as soon
> as the netdev stops the tx queue you'll get corruption.
That's perfectly valid when sendpage() returns and holds a reference to
the pages but not skb->head, so freed skb will free (and potentially
reuse) that area which has not been transmitted yet.
But without acceleration it will copy data and the whole original skb
may be freed without any problems.
--
Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists