From: Christian Brauner <christian.brauner@canonical.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Nikolay Borisov <nborisov@suse.com>,
Christian Brauner <christian.brauner@ubuntu.com>,
Linux Containers <containers@lists.linux-foundation.org>,
tycho@tycho.ws, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/5] userns: Don't read extents twice in m_start
Date: Wed, 1 Nov 2017 17:29:33 +0100 [thread overview]
Message-ID: <20171101162932.hfetkatdwcdqmqfi@gmail.com> (raw)
In-Reply-To: <20171101141654.fr4rs2m5cygouktb@hirez.programming.kicks-ass.net>
On Wed, Nov 01, 2017 at 03:16:54PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 01, 2017 at 03:01:45PM +0100, Christian Brauner wrote:
> > Tbf, this isn't solely Eric's fault. I'm to blame here too since I didn't
> > document the already existing smb_rmb()s and the new one I introduced when
> > writing the patches. I didn't know that there was a hard-set requirement to
> > document those. I also didn't see anything in the kernel coding style or the
> > memory barriers documentation (But it has been some time since I read those.).
>
> There's too many documents to read.. I'm not sure we changed
> coding-style, and I suspect that'll just end up being another bike-shed
> in any case.
>
> We did get checkpatch changed though, which is a strong enough clue that
> something needs to happen.
>
> But What Nikolay said; memory ordering is hard enough if you're clear on
> what exactly you intend to do. But if you later try and reconstruct
> without comments, its nearly impossible.
Yeah, agreed. I was happy to see that Eric explained his smp_wmb() in detail.
That was quite helpful in figuring this out!
>
> It gets even better if someone changes the ordering requirements over
> time and you grow hidden and non-obvious dependencies :/
>
> > > Also, you probably want READ_ONCE() here and WRITE_ONCE() in
> > > map_write(), the compiler is free to do unordered byte loads/stores
> > > without it.
> > >
> > > And finally, did you want to use smp_store_release() and
> > > smp_load_acquire() instead?
> >
> > Maybe a stupid question but do you suspect this is a real problem in
> > this case since you're phrasing it as a question?
>
> Rhetorical question mostly, I suspect its just what you meant to do, as
> per the proposed patch.
>
> > Iirc, *_acquire() operations include
> > locking operations and might come with a greater performance impact then
> > smb_{rmb,wmb}(). Given that this is a very performance critical path we should
> > be sure.
>
> No locking what so ever. LOAD-ACQUIRE and STORE-RELEASE are memory ordering
> flavours that are paired with the respective memory operation.
Ah right, now I remember I was confused by a part of the memory barriers
documentation that referenced locks. Acquire operations include locks and
smp_load_acquire(). Right, should've remembered that. Thanks!
>
> It is true that locking ops provide these exact orderings, but that
> doesn't imply the reverse.
>
> In short, store-release is a store that ensures all prior load _and_
> stores happen-before this store. A load-acquire is a load which
> happens-before any subsequent load or stores.
>
> But a release does not constrain later loads or stores, and an acquire
> does not constrain prior load or stores.
>
>
next prev parent reply other threads:[~2017-11-01 16:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-24 22:04 [PATCH 1/2 v6] user namespace: use union in {g,u}idmap struct Christian Brauner
2017-10-24 22:04 ` [PATCH 2/2 v6] user namespaces: bump idmap limits to 340 Christian Brauner
2017-10-31 23:46 ` [PATCH 0/5] userns: bump idmap limits, fixes & tweaks Eric W. Biederman
2017-10-31 23:47 ` [PATCH 1/5] userns: Don't special case a count of 0 Eric W. Biederman
2017-10-31 23:47 ` [PATCH 2/5] userns: Simplify the user and group mapping functions Eric W. Biederman
2017-10-31 23:48 ` [PATCH 3/5] userns: Don't read extents twice in m_start Eric W. Biederman
2017-11-01 8:31 ` Nikolay Borisov
2017-11-01 11:08 ` Eric W. Biederman
2017-11-01 13:05 ` Nikolay Borisov
2017-11-01 13:05 ` Peter Zijlstra
2017-11-01 14:01 ` Christian Brauner
2017-11-01 14:16 ` Peter Zijlstra
2017-11-01 16:29 ` Christian Brauner [this message]
2017-11-01 16:31 ` Christian Brauner
2017-11-01 17:00 ` Joe Perches
2017-11-01 17:20 ` Eric W. Biederman
2017-11-01 18:15 ` Peter Zijlstra
2017-10-31 23:48 ` [PATCH 4/5] userns: Make map_id_down a wrapper for map_id_range_down Eric W. Biederman
2017-10-31 23:49 ` [PATCH 5/5] userns: Simplify insert_extent Eric W. Biederman
2017-11-01 10:51 ` [PATCH 0/5] userns: bump idmap limits, fixes & tweaks Christian Brauner
2017-11-01 11:15 ` Eric W. Biederman
2017-11-01 13:31 ` Christian Brauner
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=20171101162932.hfetkatdwcdqmqfi@gmail.com \
--to=christian.brauner@canonical.com \
--cc=christian.brauner@ubuntu.com \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nborisov@suse.com \
--cc=peterz@infradead.org \
--cc=tycho@tycho.ws \
/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).