From: Sasha Levin <sashal@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Slavomir Kaslev <kaslevs@vmware.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH AUTOSEL 4.9 20/87] fs: Make splice() and tee() take into account O_NONBLOCK flag on pipes
Date: Wed, 3 Apr 2019 12:19:06 -0400 [thread overview]
Message-ID: <20190403161906.GD16241@sasha-vm> (raw)
In-Reply-To: <20190328120417.36bae781@gandalf.local.home>
On Thu, Mar 28, 2019 at 12:04:17PM -0400, Steven Rostedt wrote:
>On Thu, 28 Mar 2019 15:37:49 +0000
>Slavomir Kaslev <kaslevs@vmware.com> wrote:
>
>> On Wed, 2019-03-27 at 14:19 -0400, Sasha Levin wrote:
>> > From: Slavomir Kaslev <kaslevs@vmware.com>
>> >
>> > [ Upstream commit ee5e001196d1345b8fee25925ff5f1d67936081e ]
>> >
>> > The current implementation of splice() and tee() ignores O_NONBLOCK
>> > set
>> > on pipe file descriptors and checks only the SPLICE_F_NONBLOCK flag
>> > for
>> > blocking on pipe arguments. This is inconsistent since splice()-ing
>> > from/to non-pipe file descriptors does take O_NONBLOCK into
>> > consideration.
>> >
>> > Fix this by promoting O_NONBLOCK, when set on a pipe, to
>> > SPLICE_F_NONBLOCK.
>>
>> Hey Sasha,
>>
>> I don't think that this patch should be merged to stable kernels. It's
>> more of a feature rather than a bug/regression fix and it changes how
>> splice() has been working from day one.
>>
>> Can you please drop it from the stable queues?
>>
>
>On the other hand, it keeps stable more in sync with what mainline has.
>If someone writes new code against a stable release, and depends on
>this behavior, it's less likely to break when they run it on a newer
>kernel. Which means its less likely that Linus will revert your
>change ;-)
I'm going to drop this, I don't really want to take things which
knowingly might brake userspace.
--
Thanks,
Sasha
next prev parent reply other threads:[~2019-04-03 16:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190327182040.17444-1-sashal@kernel.org>
2019-03-27 18:19 ` [PATCH AUTOSEL 4.9 07/87] sysctl: handle overflow for file-max Sasha Levin
2019-03-27 18:19 ` [PATCH AUTOSEL 4.9 16/87] fs/file.c: initialize init_files.resize_wait Sasha Levin
2019-03-27 18:19 ` [PATCH AUTOSEL 4.9 20/87] fs: Make splice() and tee() take into account O_NONBLOCK flag on pipes Sasha Levin
2019-03-28 15:37 ` Slavomir Kaslev
2019-03-28 16:04 ` Steven Rostedt
2019-04-03 16:19 ` Sasha Levin [this message]
2019-03-27 18:19 ` [PATCH AUTOSEL 4.9 22/87] fs: fix guard_bio_eod to check for real EOD errors Sasha Levin
2019-03-27 18:19 ` [PATCH AUTOSEL 4.9 43/87] vfs: fix preadv64v2 and pwritev64v2 compat syscalls with offset == -1 Sasha Levin
2019-03-27 18:20 ` [PATCH AUTOSEL 4.9 55/87] genirq: Avoid summation loops for /proc/stat Sasha Levin
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=20190403161906.GD16241@sasha-vm \
--to=sashal@kernel.org \
--cc=kaslevs@vmware.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).