[<prev] [next>] [day] [month] [year] [list]
Message-ID: <7403.1567526797@warthog.procyon.org.uk>
Date: Tue, 03 Sep 2019 17:06:37 +0100
From: David Howells <dhowells@...hat.com>
To: Hillf Danton <hdanton@...a.com>
Cc: dhowells@...hat.com, viro@...iv.linux.org.uk,
Casey Schaufler <casey@...aufler-ca.com>,
Stephen Smalley <sds@...ho.nsa.gov>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
nicolas.dichtel@...nd.com, raven@...maw.net,
Christian Brauner <christian@...uner.io>,
keyrings@...r.kernel.org, linux-usb@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-api@...r.kernel.org,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 04/11] General notification queue with user mmap()'able ring buffer [ver #7]
Hillf Danton <hdanton@...a.com> wrote:
> > + smp_store_release(&buf->meta.head, head);
>
> Add a line of comment for the paring smp_load_acquire().
> I did not find it in 04/11.
You won't find smp_load_acquire() - it's not in the kernel, though if you look
in the sample, you'll find the corresponding barrier in userspace. Note that
there's a further implicit barrier you don't see.
I've added the comments:
/* Barrier against userspace, ordering data read before tail read */
ring_tail = READ_ONCE(buf->meta.tail);
and:
/* Barrier against userspace, ordering head update after data write. */
smp_store_release(&buf->meta.head, head);
David
Powered by blists - more mailing lists