[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230814161625.4a0ad49a@gandalf.local.home>
Date: Mon, 14 Aug 2023 16:16:25 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Zheng Yejian <zhengyejian1@...wei.com>, mhiramat@...nel.org,
laijs@...fujitsu.com, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org,
"Jason A. Donenfeld" <Jason@...c4.com>,
Jens Axboe <axboe@...nel.dk>, Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] tracing: Fix race when concurrently splice_read
trace_pipe
On Sun, 13 Aug 2023 09:41:33 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> So if somebody really *really* want sendfile to work for this case, then you
>
> (a) do need to fix the race in tracing_splice_read_pipe (which you
> should do anyway, since you can obviously always use splice() itself,
> not sendfile()).
>
> AND
>
> (b) figure out when 'splice_write()' will always succeed fully and
> convince people that we can do that "extended version" of sendfile().
>
No big deal. I really don't care about splicing trace_pipe anyway. That was
added by others, but the trace_pipe_raw is what really should be used.
Zheng's race needs to be fixed regardless, but I just wanted to make sure
this wasn't some kind of hidden regression, as there were patches to
trace_pipe to make sendfile get fixed in the past.
a29054d9478d0 ("tracing: Fix crash from reading trace_pipe with sendfile")
But that too was triggered by cat. If cat no longer uses sendfile for
trace_pipe, I'm fine with it.
-- Steve
Powered by blists - more mailing lists