[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrUka9KaOKFbNKUXcA6XvoFxiXPftctSHtN4DL35Cay61w@mail.gmail.com>
Date: Thu, 7 Nov 2019 10:16:13 -0800
From: Andy Lutomirski <luto@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Casey Schaufler <casey@...aufler-ca.com>,
Stephen Smalley <sds@...ho.nsa.gov>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>, raven@...maw.net,
Christian Brauner <christian@...uner.io>,
keyrings@...r.kernel.org, USB list <linux-usb@...r.kernel.org>,
linux-block <linux-block@...r.kernel.org>,
LSM List <linux-security-module@...r.kernel.org>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 04/14] pipe: Add O_NOTIFICATION_PIPE [ver #2]
On Thu, Nov 7, 2019 at 5:39 AM David Howells <dhowells@...hat.com> wrote:
>
> Add an O_NOTIFICATION_PIPE flag that can be passed to pipe2() to indicate
> that the pipe being created is going to be used for notifications. This
> suppresses the use of splice(), vmsplice(), tee() and sendfile() on the
> pipe as calling iov_iter_revert() on a pipe when a kernel notification
> message has been inserted into the middle of a multi-buffer splice will be
> messy.
How messy? And is there some way to make it impossible for this to
happen? Adding a new flag to pipe2() to avoid messy kernel code seems
like a poor tradeoff.
Powered by blists - more mailing lists