I misunderstood your prior message and/or
> misconstrued what you said -- it was not clear to me what you meant.
I think what added to my confusion here was this bit, Jens:
> > As far as the bit about plumbing only the splice bits, sorry if I'm
> > being dense here, do
you can do it
simpler this other way, why not consider that? The end result would be
the same, you can do fast sendfile() with sane buffer reuse. But the
kernel side would be simpler, which is always a kernel main goal for
those of us that have to maintain it.
Just adding sendfile2() works in the
, 2025 at 01:04:48AM -0700, Christoph Hellwig wrote:
On Wed, Mar 19, 2025 at 12:15:11AM +, Joe Damato wrote:
One way to fix this is to add zerocopy notifications to sendfile similar
to how MSG_ZEROCOPY works with sendmsg. This is possible thanks to the
extensive work done by Pavel [1].
What
On 3/19/25 5:22 PM, Joe Damato wrote:
> Would you be open to the idea that sendfile could be extended to
> generate error queue completions if the network socket has
> SO_ZEROCOPY set?
I thought I was quite clear on my view of SO_ZEROCOPY and its error
queue usage, I guess I was not. N
On Thu, Mar 20, 2025 at 11:23:57AM -0700, Joe Damato wrote:
> In my other message to Jens I proposed:
> - SPLICE_F_ZC for splice to generate zc completion notifications
> to the error queue
> - Modifying sendfile so that if SO_ZEROCOPY (which already exists)
> is s
in other messages, it seems like it is
>> possible to improve the networking parts of splice (and therefore
>> sendfile) to make them safer to use without introducing a new system
>> call.
>>
>> Are you saying that you are against doing that, even if the code is
would seem saner to
> plumb up those bits only. Would be much simpler too...
>
> wherein I interpreted "plumb those bits" to mean plumbing the error
> queue notifications on TX completions.
>
> My sincere apologies that I misunderstood your prior message and/or
> misc
logies that I misunderstood your prior message and/or
> >> misconstrued what you said -- it was not clear to me what you meant.
> >
> > I think what added to my confusion here was this bit, Jens:
> >
> > > > As far as the bit about plumbing only
would be the same as for other features - if you can do it
simpler this other way, why not consider that? The end result would be
the same, you can do fast sendfile() with sane buffer reuse. But the
kernel side would be simpler, which is always a kernel main goal for
those of us that have to maintain
ean plumbing the error
>> queue notifications on TX completions.
>>
>> My sincere apologies that I misunderstood your prior message and/or
>> misconstrued what you said -- it was not clear to me what you meant.
>
> I think what added to my confusion here was this bit, Je
On Thu, Mar 20, 2025 at 10:56:15PM -0700, Christoph Hellwig wrote:
> On Thu, Mar 20, 2025 at 11:23:57AM -0700, Joe Damato wrote:
> > In my other message to Jens I proposed:
> > - SPLICE_F_ZC for splice to generate zc completion notifications
> > to the error queue
>
ose bits" to mean plumbing the error
queue notifications on TX completions.
My sincere apologies that I misunderstood your prior message and/or
misconstrued what you said -- it was not clear to me what you meant.
It is clear to me now, though, that adding a flag to splice as
previously prop
On 3/19/25 1:16 PM, Joe Damato wrote:
>>> In general: it does seem a bit odd to me that there isn't a safe
>>> sendfile syscall in Linux that uses existing completion notification
>>> mechanisms.
>>
>> Pretty natural, I think. sendfile(2) predates that
;
> So if you don't know that why do you even do the work?
I am doing the work because I use splice and sendfile and it seems
relatively straightforward to make them safer using an existing
mechanism, at least for network sockets.
After dropping the sendfile2 patches completely, it l
or splice. I'll wait a bit to hear what Jens thinks about the
SO_ZEROCOPY thing (basically: if a network socket has that option
set, maybe the existing sendfile can generate error queue
completions without needing a separate system call?).
I agree overall that sendfile2 or sendmsg2 or whatever els
consider that? The end result would be
the same, you can do fast sendfile() with sane buffer reuse. But the
kernel side would be simpler, which is always a kernel main goal for
those of us that have to maintain it.
Just adding sendfile2() works in the sense that it's an easier drop in
replacemen
s seem a bit odd to me that there isn't a safe
> sendfile syscall in Linux that uses existing completion notification
> mechanisms.
Agreed. Where the existing notification mechanism is called io_uring.
> Of course, I certainly agree that the error queue is a work around.
> But it wor
On Wed, Mar 19, 2025 at 08:32:19AM -0700, Joe Damato wrote:
> See the docs on MSG_ZEROCOPY [1], but in short when a user app calls
> sendmsg and passes MSG_ZEROCOPY a completion notification is added
> to the error queue. The user app can poll for these to find out when
> the TX has completed and t
add zerocopy notifications to sendfile similar
> >>> to how MSG_ZEROCOPY works with sendmsg. This is possible thanks to the
> >>> extensive work done by Pavel [1].
> >>
> >> What is a "zerocopy notification"
> >
> > See the docs
add zerocopy notifications to sendfile similar
> >>> to how MSG_ZEROCOPY works with sendmsg. This is possible thanks to the
> >>> extensive work done by Pavel [1].
> >>
> >> What is a "zerocopy notification"
> >
> > See the docs
wrote:
> >>>> On 3/19/25 9:32 AM, Joe Damato wrote:
> >>>>> On Wed, Mar 19, 2025 at 01:04:48AM -0700, Christoph Hellwig wrote:
> >>>>>> On Wed, Mar 19, 2025 at 12:15:11AM +, Joe Damato wrote:
> >>>>>>> One way to fix t
> On Wed, Mar 19, 2025 at 01:04:48AM -0700, Christoph Hellwig wrote:
>>>>>> On Wed, Mar 19, 2025 at 12:15:11AM +, Joe Damato wrote:
>>>>>>> One way to fix this is to add zerocopy notifications to sendfile similar
>>>>>>> to ho
On Wed, Mar 19, 2025 at 01:04:48AM -0700, Christoph Hellwig wrote:
> On Wed, Mar 19, 2025 at 12:15:11AM +, Joe Damato wrote:
> > One way to fix this is to add zerocopy notifications to sendfile similar
> > to how MSG_ZEROCOPY works with sendmsg. This is possible thanks to th
h Hellwig wrote:
> >>>> On Wed, Mar 19, 2025 at 12:15:11AM +, Joe Damato wrote:
> >>>>> One way to fix this is to add zerocopy notifications to sendfile similar
> >>>>> to how MSG_ZEROCOPY works with sendmsg. This is possible thanks to the
> &g
to wrote:
>>>>> One way to fix this is to add zerocopy notifications to sendfile similar
>>>>> to how MSG_ZEROCOPY works with sendmsg. This is possible thanks to the
>>>>> extensive work done by Pavel [1].
>>>>
>>>> What is a &q
On 3/19/25 9:32 AM, Joe Damato wrote:
> On Wed, Mar 19, 2025 at 01:04:48AM -0700, Christoph Hellwig wrote:
>> On Wed, Mar 19, 2025 at 12:15:11AM +, Joe Damato wrote:
>>> One way to fix this is to add zerocopy notifications to sendfile similar
>>> to how MSG_ZEROCOPY
On Wed, Mar 19, 2025 at 12:15:11AM +, Joe Damato wrote:
> One way to fix this is to add zerocopy notifications to sendfile similar
> to how MSG_ZEROCOPY works with sendmsg. This is possible thanks to the
> extensive work done by Pavel [1].
What is a "zerocopy notification"
Extend the existing the msg_zerocopy test to allow testing sendfile to
ensure that notifications are generated.
Signed-off-by: Joe Damato
---
tools/testing/selftests/net/msg_zerocopy.c | 54 -
tools/testing/selftests/net/msg_zerocopy.sh | 5 ++
2 files changed, 58
e mode 100644
index ..0bd3c76ea6f2
--- /dev/null
+++ b/include/linux/sendfile.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef SENDFILE_H
+#define SENDFILE_H
+
+#define SENDFILE_DEFAULT (0x1) /* normal sendfile */
+#define SENDFILE_ZC (0x2) /* sendfile
Greetings:
Welcome to the RFC.
Currently, when a user app uses sendfile the user app has no way to know
if the bytes were transmit; sendfile simply returns, but it is possible
that a slow client on the other side may take time to receive and ACK
the bytes. In the meantime, the user app which
The pull request you sent on Sun, 14 Feb 2021 15:19:27 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.sendfile
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/054560e961a0ee4067fccfcfa943335e1aa48928
Thank you!
--
Deet-doot-dot, I am a bot.
On Sun, Feb 14, 2021 at 11:35:36AM -0800, Linus Torvalds wrote:
> Just to clarify: this says "fixes", but I get the feeling that you
> meant for me to pull tomorrow in the 5.12 merge window?
>
> I like the patches, but they don't seem to be anything hugely urgent.
>
On Sun, Feb 14, 2021 at 7:19 AM Al Viro wrote:
>
> Making sendfile() to pipe destination do the right thing, should
> make "fs/pipe: allow sendfile() to pipe again" redundant. Sat in -next
> for 3 weeks...
Just to clarify: this says "fixes", but I get t
Making sendfile() to pipe destination do the right thing, should
make "fs/pipe: allow sendfile() to pipe again" redundant. Sat in -next
for 3 weeks...
The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:
Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)
are
On Tue, Jan 26, 2021 at 10:57:38AM -0800, Linus Torvalds wrote:
> On Mon, Jan 25, 2021 at 10:09 PM Al Viro wrote:
> >
> > no point going through the intermediate pipe
>
> Ok, this series looks fine to me.
>
> Al - do you want me to apply this as patches for 5.11 (and I'll revert
> the then unnec
On Mon, Jan 25, 2021 at 10:09 PM Al Viro wrote:
>
> no point going through the intermediate pipe
Ok, this series looks fine to me.
Al - do you want me to apply this as patches for 5.11 (and I'll revert
the then unnecessary one-liner), or should I expect a pull request or
what?
Lin
After commit 36e2c7421f02 ("fs: don't allow splice read/write
without explicit ops") sendfile() could no longer send data
from a real file to a pipe, breaking for example certain cgit
setups (e.g. when running behind fcgiwrap), because in this
case cgit will try to do exactly this:
Looks good,
Reviewed-by: Christoph Hellwig
no point going through the intermediate pipe
Signed-off-by: Al Viro
---
fs/internal.h | 9 +
fs/read_write.c | 19 +--
fs/splice.c | 2 +-
3 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/fs/internal.h b/fs/internal.h
index 77c50befbfbe..cff1f30cfef
On Mon, Jan 25, 2021 at 1:16 AM Johannes Berg wrote:
>
> Mostly for the record, since it looks like we'll have a proper
> fix without another intermediate pipe. However, this fixes the
> regression for now.
I've applied this anyway.
We'll see how big Al's proper fix ends up being, and depending
On 1/20/21 9:46 PM, Christoph Hellwig wrote:
> Hi Greg and Tejun,
>
> this fixes a regression in Linux 5.10 that stopped sendfile and splice
> from working on kernfs/sysfs files.
>
> Diffstt:
> file.c | 65
> ---
On Wed, Jan 20, 2021 at 09:46:28PM +0100, Christoph Hellwig wrote:
> Hi Greg and Tejun,
>
> this fixes a regression in Linux 5.10 that stopped sendfile and splice
> from working on kernfs/sysfs files.
>
> Diffstt
Hi Greg and Tejun,
this fixes a regression in Linux 5.10 that stopped sendfile and splice
from working on kernfs/sysfs files.
Diffstt:
file.c | 65 -
1 file changed, 24 insertions(+), 41 deletions(-)
On 1/20/2021 1:10 AM, Christoph Hellwig wrote:
Can you give this patch a spin?
Thanks! This patch fixed the fallback mechanism for me. Attaching logs:
[ 84.410162][ T244] qcom_q6v5_pas .remoteproc-cdsp: Direct
firmware load for cdsp.bX failed with error -2
[ 84.418276][ T244] q
Can you give this patch a spin?
diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
index f277d023ebcd14..4b5833b3059f9c 100644
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "kernfs-internal.h"
@@ -180,11 +181,10 @@ static c
lice_{read,write} functions the
calls to splice_{read,write} used the default kernel_{read,write} functions.
With the above change this results in an -EINVAL return from
do_splice_from[4].
This essentially means that sendfile will not work for any binary attribute
in the sysfs.
Have you tried fixing
ge this results in an -EINVAL return from
> > > > > > > do_splice_from[4].
> > > > > > >
> > > > > > > This essentially means that sendfile will not work for any binary
> > > > > > > attribute
> > > > > &g
tions.
With the above change this results in an -EINVAL return from
do_splice_from[4].
This essentially means that sendfile will not work for any binary attribute
in the sysfs.
Have you tried fixing this with a patch much like what we did for the
proc files that needed this? If not, can you?
I a
the default kernel_{read,write}
> > > > > functions.
> > > > > With the above change this results in an -EINVAL return from
> > > > > do_splice_from[4].
> > > > >
> > > > > This essentially means that sendfile will not wo
plice
read/write without explicit ops"[1] the fallback mechanism of the firmware
loader[2] no longer works when using sendfile[3] from the userspace.
What userspace program are you using to load firmware?
The userspace program is in the android userspace which listens to a uevent
from the firm
don't allow splice
> > > read/write without explicit ops"[1] the fallback mechanism of the firmware
> > > loader[2] no longer works when using sendfile[3] from the userspace.
> > What userspace program are you using to load firmware?
> The userspace program is
orks when using sendfile[3] from the userspace.
What userspace program are you using to load firmware?
The userspace program is in the android userspace which listens to a
uevent from the firmware loader and then loads the firmware using
sendfile[1].
Are you not using the in-kernel firmware
On Mon, Jan 04, 2021 at 02:43:45PM -0800, Siddharth Gupta wrote:
> Hi all,
>
> With the introduction of the filesystem change "fs: don't allow splice
> read/write without explicit ops"[1] the fallback mechanism of the firmware
> loader[2] no longer works when using
Hi all,
With the introduction of the filesystem change "fs: don't allow splice
read/write without explicit ops"[1] the fallback mechanism of the
firmware loader[2] no longer works when using sendfile[3] from the
userspace.
Since the binary attributes don't suppor
From: Rohit Maheshwari
[ Upstream commit ea1dd3e9d080c961b9a451130b61c72dc9a5397b ]
At first when sendpage gets called, if there is more data, 'more' in
tls_push_data() gets set which later sets pending_open_record_frags, but
when there is no more data in file left, and last time tls_push_data()
From: Rohit Maheshwari
[ Upstream commit ea1dd3e9d080c961b9a451130b61c72dc9a5397b ]
At first when sendpage gets called, if there is more data, 'more' in
tls_push_data() gets set which later sets pending_open_record_frags, but
when there is no more data in file left, and last time tls_push_data()
From: Rohit Maheshwari
[ Upstream commit ea1dd3e9d080c961b9a451130b61c72dc9a5397b ]
At first when sendpage gets called, if there is more data, 'more' in
tls_push_data() gets set which later sets pending_open_record_frags, but
when there is no more data in file left, and last time tls_push_data()
From: Rohit Maheshwari
[ Upstream commit ea1dd3e9d080c961b9a451130b61c72dc9a5397b ]
At first when sendpage gets called, if there is more data, 'more' in
tls_push_data() gets set which later sets pending_open_record_frags, but
when there is no more data in file left, and last time tls_push_data()
perf trace: Add "sendfile64" alias to the "sendfile" syscall
We were looking in tracefs for:
/sys/kernel/debug/tracing/events/syscalls/sys_enter_sendfile/format when
what is there is just
/sys/kernel/debug/tracing/events/syscalls/sys_enter_sendfile/format
Its the same
*/ },
[1] = { .scnprintf = SCA_SECCOMP_FLAGS, /* flags */ }, }, },
{ .name = "select", .timeout = true, },
+ { .name = "sendfile", .alias = "sendfile64", },
{ .name = "sendmmsg",
.arg = { [3]
*/ },
[1] = { .scnprintf = SCA_SECCOMP_FLAGS, /* flags */ }, }, },
{ .name = "select", .timeout = true, },
+ { .name = "sendfile", .alias = "sendfile64", },
{ .name = "sendmmsg",
.arg = { [3]
From: chen jie
sendfile() softlockup for big files
[34922.213193] [Softlockup Clock][34922213187422]
[34922.213204] BUG: soft lockup - CPU#1 stuck for 60008ms! [trinity-c1:20239]
[34922.213211] Modules linked in: rtos_snapshot(O) rsm(O) nfsv3 veth(O)
higmac(O) comm(O) nand mtdblock mtd_blkdevs
3.18-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit c725bfce7968009756ed2836a8cd7ba4dc163011 ]
Commit 296291cdd162 (mm: make sendfile(2) killable) fixed an issue where
sendfile(2) was doing a lot of tiny writes into a filesystem and
From: Jan Kara
[ Upstream commit c725bfce7968009756ed2836a8cd7ba4dc163011 ]
Commit 296291cdd162 (mm: make sendfile(2) killable) fixed an issue where
sendfile(2) was doing a lot of tiny writes into a filesystem and thus
was unkillable for a long time. However sendfile(2) can be (mis)used to
On 3/25/18 11:39 PM, Eric Valette wrote:
On 3/25/18 11:07 PM, Eric Valette wrote:
Since a few kernels I get this error when streaming video to TV via
minidlna:
Checked it started with at least 4.14.25. My older kern.log.2.gz file
says before first march I did not get this error. But I removed
On 3/25/18 11:07 PM, Eric Valette wrote:
Since a few kernels I get this error when streaming video to TV via
minidlna:
Checked it started with at least 4.14.25. My older kern.log.2.gz file
says before first march I did not get this error. But I removed older
kernels from my /boot directory.
Since a few kernels I get this error when streaming video to TV via
minidlna:
Please CC me, I'm not subscribed
BUG: unable to handle kernel NULL pointer dereference at 0078
[ 3330.960519] IP: tcp_push+0x70/0xeb
[ 3330.960520] PGD 0 P4D 0
[ 3330.960523] Oops: [#1] SMP PTI
[ 3330
I tried to sendfile() a file which is larger than 4GB to a pipe (which is
the stdout of Apache's CGI program), and noticed that sendfile() fails with
EFBIG after 2GB is copied to stdout pipe. This is because sendfile() is
updating file offset of the file descriptor of the pipe.
sendfile() s
Hello.
I tried to sendfile() a file which is larger than 4GB to a pipe (which is
the stdout of Apache's CGI program) using 3.10.0-514.16.1.el7.x86_64 kernel,
and noticed that sendfile() fails with EFBIG after 2GB is copied to stdout pipe.
I confirmed using 4.12.0-rc1 kernel that sendfile()
sizes (in megabytes) the difference between what
> > sendfile is reporting and actual file size can be 3x.
> > In the small file case (like above dump) it looks rounded to page size for
> > some reason.
>
> OK, I think I see one bug in there; could you check if this gets it back
On Wed, Nov 23, 2016 at 12:58:11AM -0800, Alexei Starovoitov wrote:
> if I read it correctly 9p actually responded with 8192 bytes of requests...
> whereas the file size was 9624.
> For large file sizes (in megabytes) the difference between what
> sendfile is reporting and actual file
gt; Hi Al,
> > > >
> > > > it seems the following commit 523ac9afc73a ("switch
> > > > default_file_splice_read() to use of pipe-backed iov_iter")
> > > > breaks sendfile from 9p fs into af_alg socket.
> > > > sendfile into af_alg
llowing commit 523ac9afc73a ("switch
> > > default_file_splice_read() to use of pipe-backed iov_iter")
> > > breaks sendfile from 9p fs into af_alg socket.
> > > sendfile into af_alg is used by iproute2/tc.
> > > I'm not sure whether it's 9p or crypto or vfs
On Wed, Nov 23, 2016 at 04:46:26AM +, Al Viro wrote:
> On Tue, Nov 22, 2016 at 07:58:29PM -0800, Alexei Starovoitov wrote:
> > Hi Al,
> >
> > it seems the following commit 523ac9afc73a ("switch
> > default_file_splice_read() to use of pipe-backed iov_iter&
On Tue, Nov 22, 2016 at 07:58:29PM -0800, Alexei Starovoitov wrote:
> Hi Al,
>
> it seems the following commit 523ac9afc73a ("switch
> default_file_splice_read() to use of pipe-backed iov_iter")
> breaks sendfile from 9p fs into af_alg socket.
> sendfile into af_alg i
Hi Al,
it seems the following commit 523ac9afc73a ("switch default_file_splice_read()
to use of pipe-backed iov_iter")
breaks sendfile from 9p fs into af_alg socket.
sendfile into af_alg is used by iproute2/tc.
I'm not sure whether it's 9p or crypto or vfs problem, but happy
don't have any
scheduling point at that path in sendfile(2) implementation:
int r1 = eventfd(0, 0);
int r2 = memfd_create("", 0);
unsigned long n = 1<<30;
fallocate(r2, 0, 0, n);
sendfile(r1, r2, 0, n);
Add cond_resched() into __splice_f
From: Jan Kara
3.4.113-rc1 review patch. If anyone has any objections, please let me know.
--
commit c725bfce7968009756ed2836a8cd7ba4dc163011 upstream.
Commit 296291cdd162 (mm: make sendfile(2) killable) fixed an issue where
sendfile(2) was doing a lot of tiny writes into a
From: "Steven Rostedt (Red Hat)"
commit a29054d9478d0435ab01b7544da4f674ab13f533 upstream.
If tracing contains data and the trace_pipe file is read with sendfile(),
then it can trigger a NULL pointer dereference and various BUG_ON within the
VM code.
There's a patch to
3.16.35-rc1 review patch. If anyone has any objections, please let me know.
--
From: "Steven Rostedt (Red Hat)"
commit a29054d9478d0435ab01b7544da4f674ab13f533 upstream.
If tracing contains data and the trace_pipe file is read with sendfile(),
then it can trig
3.2.80-rc1 review patch. If anyone has any objections, please let me know.
--
From: "Steven Rostedt (Red Hat)"
commit a29054d9478d0435ab01b7544da4f674ab13f533 upstream.
If tracing contains data and the trace_pipe file is read with sendfile(),
then it can trig
From: Christophe Leroy
3.4.112-rc1 review patch. If anyone has any objections, please let me know.
--
commit 0ff28d9f4674d781e492bcff6f32f0fe48cf0fed upstream.
Using sendfile with below small program to get MD5 sums of some files,
it appear that big files (over 64kbytes with
From: Jan Kara
3.4.112-rc1 review patch. If anyone has any objections, please let me know.
--
commit 296291cdd1629c308114504b850dc343eabc2782 upstream.
Currently a simple program below issues a sendfile(2) system call which
takes about 62 days to complete in my test KVM
From: "Steven Rostedt (Red Hat)"
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit a29054d9478d0435ab01b7544da4f674ab13f533 upstream.
If tracing contains data and the trace_pipe file is read with sendfile(),
then it can trigger a NU
4.5-stable review patch. If anyone has any objections, please let me know.
--
From: Steven Rostedt (Red Hat)
commit a29054d9478d0435ab01b7544da4f674ab13f533 upstream.
If tracing contains data and the trace_pipe file is read with sendfile(),
then it can trigger a NULL pointer
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Steven Rostedt (Red Hat)
commit a29054d9478d0435ab01b7544da4f674ab13f533 upstream.
If tracing contains data and the trace_pipe file is read with sendfile(),
then it can trigger a NULL pointer
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Steven Rostedt (Red Hat)
commit a29054d9478d0435ab01b7544da4f674ab13f533 upstream.
If tracing contains data and the trace_pipe file is read with sendfile(),
then it can trigger a NULL pointer
ace_pipe file is read with sendfile(),
then it can trigger a NULL pointer dereference and various BUG_ON within the
VM code.
There's a patch to fix this in the splice_to_pipe() code, but it's also a
good idea to not let that happen from trace_pipe either.
Link: http://lkml.kernel.org/
ace_pipe file is read with sendfile(),
then it can trigger a NULL pointer dereference and various BUG_ON within the
VM code.
There's a patch to fix this in the splice_to_pipe() code, but it's also a
good idea to not let that happen from trace_pipe either.
Link: http://lkml.kernel.org/
_pipe file is read with sendfile(),
then it can trigger a NULL pointer dereference and various BUG_ON within the
VM code.
There's a patch to fix this in the splice_to_pipe() code, but it's also a
good idea to not let that happen from trace_pipe either.
Link: http://lkml.kernel.org/r/145
From: "Steven Rostedt (Red Hat)"
If tracing contains data and the trace_pipe file is read with sendfile(),
then it can trigger a NULL pointer dereference and various BUG_ON within the
VM code.
There's a patch to fix this in the splice_to_pipe() code, but it's also a
good
From: Christophe Leroy
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 0ff28d9f4674d781e492bcff6f32f0fe48cf0fed upstream.
Using sendfile with below small program to get MD5 sums of some files,
it appear that big files (over 64kbytes with 4k
don't have any
scheduling point at that path in sendfile(2) implementation:
int r1 = eventfd(0, 0);
int r2 = memfd_create("", 0);
unsigned long n = 1<<30;
fallocate(r2, 0, 0, n);
sendfile(r1, r2, 0, n);
Add cond_resched() into __splice_f
don't have any
scheduling point at that path in sendfile(2) implementation:
int r1 = eventfd(0, 0);
int r2 = memfd_create("", 0);
unsigned long n = 1<<30;
fallocate(r2, 0, 0, n);
sendfile(r1, r2, 0, n);
Add cond_resched() into __splice_f
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Christophe Leroy
commit 0ff28d9f4674d781e492bcff6f32f0fe48cf0fed upstream.
Using sendfile with below small program to get MD5 sums of some files,
it appear that big files (over 64kbytes with
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Christophe Leroy
commit 0ff28d9f4674d781e492bcff6f32f0fe48cf0fed upstream.
Using sendfile with below small program to get MD5 sums of some files,
it appear that big files (over 64kbytes with
don't have any
scheduling point at that path in sendfile(2) implementation:
int r1 = eventfd(0, 0);
int r2 = memfd_create("", 0);
unsigned long n = 1<<30;
fallocate(r2, 0, 0, n);
sendfile(r1, r2, 0, n);
Add cond_resched() into __splice_f
we don't have any
scheduling point at that path in sendfile(2) implementation:
int r1 = eventfd(0, 0);
int r2 = memfd_create("", 0);
unsigned long n = 1<<30;
fallocate(r2, 0, 0, n);
sendfile(r1, r2, 0, n);
Add cond_resched() into __spli
eventfd and we don't have any
scheduling point at that path in sendfile(2) implementation:
int r1 = eventfd(0, 0);
int r2 = memfd_create("", 0);
unsigned long n = 1<<30;
fallocate(r2, 0, 0, n);
sendfile(r1, r2, 0, n);
Add cond_resched() in
3.16.7-ckt22 -stable review patch. If anyone has any objections, please let me
know.
--
From: Jan Kara
commit c725bfce7968009756ed2836a8cd7ba4dc163011 upstream.
Commit 296291cdd162 (mm: make sendfile(2) killable) fixed an issue where
sendfile(2) was doing a lot of tiny
1 - 100 of 598 matches
Mail list logo
