linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nadav Amit <nadav.amit@gmail.com>
To: Linus Torvalds <torvalds@linuxfoundation.org>
Cc: Will Deacon <will@kernel.org>, Jann Horn <jannh@google.com>,
	"Paul E. McKenney" <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 Mailing List <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	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: Fri, 28 Jul 2023 02:18:20 -0700	[thread overview]
Message-ID: <802750CF-1C45-4F10-920A-CE7C55DBF3B2@gmail.com> (raw)
In-Reply-To: <2229115A-23F2-4B6B-800C-7182199DF79D@gmail.com>



> On Jul 27, 2023, at 1:11 PM, Nadav Amit <nadav.amit@gmail.com> wrote:
> 
> 
> 
>> On Jul 27, 2023, at 12:39 PM, Linus Torvalds <torvalds@linuxfoundation.org> wrote:
>> 
>> On Thu, 27 Jul 2023 at 12:10, Nadav Amit <nadav.amit@gmail.com> wrote:
>>> 
>>> Interesting. I wonder if you considered adding to READ_ONCE() something
>>> like:
>>> 
>>>       asm volatile("" : "+g" (x) );
>>> 
>>> So later loads (such as baz = *ptr) would reload the updated value.
>> 
>> Not necessarily a bad idea.  Although I suspect you'd want to add
>> *two* of them - on either side - to make sure any previous loads
>> wouldn't be moved around it either.
> 
> You are right, two are needed.
> 
> I’ll give it a shot and see if I see changes to the binary.

Just for the record (so nobody will make my mistakes):

I implemented it, but it works poorly. It appears to communicate the
constraints but the generated code is much worse.

The problem is that if the GCC inline asm decides to use a memory operand
(e.g. “+m”), it computes the address (uses LEA first before the MOV) and
allocates a register for the address. Using “+g” also causes the compiler
to allocate a register.

-- >8 --

---
 include/asm-generic/rwonce.h | 32 ++++++++++++++++++++++++++++----
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h
index 8d0a6280e982..c6a2f8e3013c 100644
--- a/include/asm-generic/rwonce.h
+++ b/include/asm-generic/rwonce.h
@@ -44,10 +44,34 @@
 #define __READ_ONCE(x)	(*(const volatile __unqual_scalar_typeof(x) *)&(x))
 #endif
 
-#define READ_ONCE(x)							\
-({									\
-	compiletime_assert_rwonce_type(x);				\
-	__READ_ONCE(x);							\
+#define as_scalar(x)							\
+    __builtin_choose_expr(sizeof(x) == sizeof(char),  			\
+				(__force char *)&(x), 			\
+    __builtin_choose_expr(sizeof(x) == sizeof(short),			\
+				(__force short *)&(x),			\
+    __builtin_choose_expr(sizeof(x) == sizeof(int),			\
+				(__force int *)&(x), 			\
+    __builtin_choose_expr(sizeof(x) == sizeof(long),			\
+				(__force long *)&(x),			\
+    __builtin_choose_expr(sizeof(x) == sizeof(long long),		\
+				(__force long long *)&(x),		\
+    (void*)0)))))
+
+#define READ_ONCE(x)                                                    \
+({                                                                      \
+    typeof(x) * px = &(x);						\
+    union {								\
+        typeof(x) __orig;						\
+        typeof(*as_scalar(x)) __alias;					\
+    } __u;								\
+									\
+    compiletime_assert_rwonce_type(x);					\
+    asm volatile ("" :							\
+               "+g" (*(__force typeof(*as_scalar(x)) *)(px)));		\
+    __u.__alias = __READ_ONCE(*as_scalar(*px));				\
+    asm volatile ("" :							\
+               "+g" (*(__force typeof(*as_scalar(x)) *)(px)));		\
+    __u.__orig;								\
 })
 
 #define __WRITE_ONCE(x, val)						\
-- 
2.34.1




  reply	other threads:[~2023-07-28  9:18 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-26 21:41 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
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 [this message]
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

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=802750CF-1C45-4F10-920A-CE7C55DBF3B2@gmail.com \
    --to=nadav.amit@gmail.com \
    --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=torvalds@linuxfoundation.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox