From: Stephen Hemminger <shemminger@vyatta•com>
To: netdev@vger•kernel.org
Subject: Fw: [Bug 42699] New: vmsplice() appears to be returning to caller while buffers are still in use
Date: Mon, 30 Jan 2012 19:48:34 -0800 [thread overview]
Message-ID: <20120130194834.024a5e5a@nehalam.linuxnetplumber.net> (raw)
IMHO vmsplice() is like splice() and the caller needs to assume that buffers
are in use. This semantic goes all the way back to the earlier sendfile.
Begin forwarded message:
Date: Tue, 31 Jan 2012 02:26:27 GMT
From: bugzilla-daemon@bugzilla•kernel.org
To: shemminger@linux-foundation•org
Subject: [Bug 42699] New: vmsplice() appears to be returning to caller while buffers are still in use
https://bugzilla.kernel.org/show_bug.cgi?id=42699
Summary: vmsplice() appears to be returning to caller while
buffers are still in use
Product: Networking
Version: 2.5
Kernel Version: 2.6.38.6-26.rc1.fc15.i686
Platform: All
OS/Version: Linux
Tree: Fedora
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
AssignedTo: shemminger@linux-foundation•org
ReportedBy: vomlehn@texas•net
Regression: No
Created an attachment (id=72238)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72238)
User space code demonstrating the issue into a loopback scenario
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/)
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
reply other threads:[~2012-01-31 3:48 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120130194834.024a5e5a@nehalam.linuxnetplumber.net \
--to=shemminger@vyatta$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox