All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linuxfoundation.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Will Deacon <will@kernel.org>, Jann Horn <jannh@google.com>,
	paulmck@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Matthew Wilcox <willy@infradead.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Andrea Parri <parri.andrea@gmail.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	David Howells <dhowells@redhat.com>,
	Jade Alglave <j.alglave@ucl.ac.uk>,
	Luc Maranget <luc.maranget@inria.fr>,
	Akira Yokosawa <akiyks@gmail.com>,
	Daniel Lustig <dlustig@nvidia.com>,
	Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 0/2] fix vma->anon_vma check for per-VMA locking; fix anon_vma memory ordering
Date: Thu, 27 Jul 2023 11:01:39 -0700	[thread overview]
Message-ID: <CAHk-=whXP+27F-k7qrkmMYRZLD1Q05expC2x=esgC5qJJS7M1A@mail.gmail.com> (raw)
In-Reply-To: <af1eed90-a1d5-4da0-84a0-05e61767ab37@rowland.harvard.edu>

On Thu, 27 Jul 2023 at 10:41, Alan Stern <stern@rowland.harvard.edu> wrote:
>
> But in the presence of data races (as in the example that Will posted
> earlier), all bets are off.  So if you want to use a plain access rather
> than READ_ONCE, you need to be certain that it won't race with anything.

So in this case, the initial NULL check really is just checking for
"has the smp_store_release() happened". The reason even tearing
wouldn't matter is that seeing *any* value other than all-zeroes (aka
NULL) is already sufficient information.

Because once the smp_store_release() has been seen by this CPU, the
data race no longer exists, and the value is stable.

Which is why I argue that even without READ_ONCE() the code would
*work* due to all the circumstances around it (one of them is that we
just took a lock, after doing an optimistic check that really has no
semantic effect at all except for the "don't even take the lock if it
looks like things are going to fail").

But if we want to have the code be obvious, and not have to refer to
those kinds of arguments, I think smp_load_acquire() is the only
actual "obvious" thing to use. At that point it's no longer some chain
of "because of X, Y and Z".

              Linus

  reply	other threads:[~2023-07-27 18:02 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-26 21:41 [PATCH 0/2] fix vma->anon_vma check for per-VMA locking; fix anon_vma memory ordering Jann Horn
2023-07-26 21:41 ` [PATCH 1/2] mm: lock_vma_under_rcu() must check vma->anon_vma under vma lock Jann Horn
2023-07-27 21:52   ` Suren Baghdasaryan
2023-07-26 21:41 ` [PATCH 2/2] mm: Fix anon_vma memory ordering Jann Horn
2023-07-26 21:50   ` Jann Horn
2023-07-27 18:25     ` Linus Torvalds
2023-07-26 23:19 ` [PATCH 0/2] fix vma->anon_vma check for per-VMA locking; fix " Paul E. McKenney
2023-07-27 14:39   ` Jann Horn
2023-07-27 14:57     ` Will Deacon
2023-07-27 15:44       ` Alan Stern
2023-07-27 16:10         ` Jann Horn
2023-07-27 16:17           ` Paul E. McKenney
2023-07-27 16:16         ` Paul E. McKenney
2023-07-27 17:11         ` Linus Torvalds
2023-07-27 17:41           ` Alan Stern
2023-07-27 18:01             ` Linus Torvalds [this message]
2023-07-27 19:05       ` Nadav Amit
2023-07-27 19:39         ` Linus Torvalds
2023-07-27 20:11           ` Nadav Amit
2023-07-28  9:18             ` Nadav Amit
2023-07-27 15:07     ` Matthew Wilcox
2023-07-27 15:15       ` Jann Horn
2023-07-27 16:09       ` Paul E. McKenney
2023-07-27 16:34 Joel Fernandes
2023-07-28 12:44 ` Will Deacon
2023-07-28 17:35   ` Joel Fernandes
2023-07-28 17:51     ` Alan Stern
2023-07-28 18:03       ` Joel Fernandes
2023-07-28 18:18         ` Paul E. McKenney
2023-07-28 19:50           ` Joel Fernandes

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='CAHk-=whXP+27F-k7qrkmMYRZLD1Q05expC2x=esgC5qJJS7M1A@mail.gmail.com' \
    --to=torvalds@linuxfoundation.org \
    --cc=akiyks@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=boqun.feng@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=dlustig@nvidia.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=jannh@google.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luc.maranget@inria.fr \
    --cc=npiggin@gmail.com \
    --cc=parri.andrea@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=stern@rowland.harvard.edu \
    --cc=surenb@google.com \
    --cc=will@kernel.org \
    --cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.