vmsplice() appears to be returning to caller while buffers are still in use

vmsplice() appears to be returning to caller while buffers are still in use

[David VomLehn]

(Apologies to anyone who has already seen this--didn't realize the mailing
list changed from linux-net to netdev)
Entered in kernel bug tracker as bug #42699.

This problem appears to occur both with sending packets over a network and with
the loopback device, though the specifics vary slightly. The simplest case is a
loopback. When task A sends a big buffer to task B, an sk_buff will be set up
with the mapped buffer as sk_bufs data. The problem is that vmsplice appears to
return to task A at that point, even though task B may not have read any or all
of the data. When task A writes to the buffer, it overwrites the data being
sent to task B, even though task B has not read the data. Thus, task B gets
corrupted data.

The scenario with TCP appears similar, but can be worse because of the
requirement to keep the buffer around for quite a while in order to
retransmitted if necessary.

So long as task A is writing data into the buffer area intended for task B,
this is only a data corruption issue. This may not be the case, however. Should
task A write data intended for some other use into the memory that had been
used for the buffer, that data can leak to task B.

One possible fix would be to add the ability to support sk_buff- or
page-specific notifiers to handle buffer freeing, rather like Ian Campbell's
recent proposal (http://lwn.net/Articles/474791/)

The Bugzilla report has code attached for the loopback case.
-- 
David VL