[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7772.1573195370@warthog.procyon.org.uk>
Date: Fri, 08 Nov 2019 06:42:50 +0000
From: David Howells <dhowells@...hat.com>
To: Andy Lutomirski <luto@...nel.org>
Cc: dhowells@...hat.com,
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]
Andy Lutomirski <luto@...nel.org> wrote:
> I can open a normal pipe from userspace (with pipe() or pipe2()), and
> I can have two threads. One thread writes to the pipe with write().
> The other thread writes with splice(). Everything works fine.
Yes. Every operation you do on a pipe from userspace is serialised with the
pipe mutex - and both ends share the same pipe.
> What's special about notifications?
The post_notification() cannot take the pipe mutex. It has to be callable
from softirq context. Linus's idea is that when you're actually altering the
ring pointers you should hold the wake-queue spinlock, and post_notification()
holds the wake queue spinlock for the duration of the operation.
This means that post_notification() can be writing to the pipe whilst a
userspace-invoked operation is holding the pipe mutex and is also doing
something to the ring.
David
Powered by blists - more mailing lists