From: Linus Torvalds <torvalds@linux-foundation.org> To: "Paul E. McKenney" <paulmck@linux.ibm.com> Cc: Herbert Xu <herbert@gondor.apana.org.au>, Frederic Weisbecker <fweisbec@gmail.com>, Boqun Feng <boqun.feng@gmail.com>, Fengguang Wu <fengguang.wu@intel.com>, LKP <lkp@01.org>, LKML <linux-kernel@vger.kernel.org>, Netdev <netdev@vger.kernel.org>, "David S. Miller" <davem@davemloft.net> Subject: Re: rcu_read_lock lost its compiler barrier Date: Mon, 3 Jun 2019 13:24:32 -0700 [thread overview] Message-ID: <CAHk-=whXb-QGZqOZ7S9YdjvQf7FNymzceinzJegvRALqXm3=FQ@mail.gmail.com> (raw) In-Reply-To: <20190603195304.GK28207@linux.ibm.com> On Mon, Jun 3, 2019 at 12:53 PM Paul E. McKenney <paulmck@linux.ibm.com> wrote: > > I agree that !PREEMPT rcu_read_lock() would not affect compiler code > generation, but given that get_user() is a volatile asm, isn't the > compiler already forbidden from reordering it with the volatile-casted > WRITE_ONCE() access, even if there was nothing at all between them? > Or are asms an exception to the rule that volatile executions cannot > be reordered? Paul, you MAKE NO SENSE. What is wrong with you? I just showed you an example of where rcu_read_lock() needs to be a compiler barrier, and then you make incoherent noises about WRITE_ONCE() that do not even exist in that example. Forget about your READ_ONCE/WRITE_ONCE theories. Herbert already showed code that doesn't have those accessors, so reality doesn't match your fevered imagination. And sometimes it's not even possible, since you can't do a bitfield access, for exmaple, with READ_ONCE(). > We can of course put them back in, Stop the craziness. It's not "we can". It is a "we will". So I will add that barrier, and you need to stop arguing against it based on specious theoretical arguments that do not match reality. And we will not ever remove that barrier again. Herbert already pointed to me having to do this once before in commit 386afc91144b ("spinlocks and preemption points need to be at least compiler barriers"), and rcu_read_lock() clearly has at a minimum that same preemption point issue. Linus
WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org> To: lkp@lists.01.org Subject: Re: rcu_read_lock lost its compiler barrier Date: Mon, 03 Jun 2019 13:24:32 -0700 [thread overview] Message-ID: <CAHk-=whXb-QGZqOZ7S9YdjvQf7FNymzceinzJegvRALqXm3=FQ@mail.gmail.com> (raw) In-Reply-To: <20190603195304.GK28207@linux.ibm.com> [-- Attachment #1: Type: text/plain, Size: 1540 bytes --] On Mon, Jun 3, 2019 at 12:53 PM Paul E. McKenney <paulmck@linux.ibm.com> wrote: > > I agree that !PREEMPT rcu_read_lock() would not affect compiler code > generation, but given that get_user() is a volatile asm, isn't the > compiler already forbidden from reordering it with the volatile-casted > WRITE_ONCE() access, even if there was nothing at all between them? > Or are asms an exception to the rule that volatile executions cannot > be reordered? Paul, you MAKE NO SENSE. What is wrong with you? I just showed you an example of where rcu_read_lock() needs to be a compiler barrier, and then you make incoherent noises about WRITE_ONCE() that do not even exist in that example. Forget about your READ_ONCE/WRITE_ONCE theories. Herbert already showed code that doesn't have those accessors, so reality doesn't match your fevered imagination. And sometimes it's not even possible, since you can't do a bitfield access, for exmaple, with READ_ONCE(). > We can of course put them back in, Stop the craziness. It's not "we can". It is a "we will". So I will add that barrier, and you need to stop arguing against it based on specious theoretical arguments that do not match reality. And we will not ever remove that barrier again. Herbert already pointed to me having to do this once before in commit 386afc91144b ("spinlocks and preemption points need to be at least compiler barriers"), and rcu_read_lock() clearly has at a minimum that same preemption point issue. Linus
next prev parent reply other threads:[~2019-06-03 20:24 UTC|newest] Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-09-10 0:57 [rcu] kernel BUG at include/linux/pagemap.h:149! Fengguang Wu 2015-09-10 0:57 ` Fengguang Wu 2015-09-10 10:25 ` Boqun Feng 2015-09-10 17:16 ` Paul E. McKenney 2015-09-10 17:16 ` Paul E. McKenney 2015-09-11 2:19 ` Boqun Feng [not found] ` <CAJzB8QG=1iZW3dQEie6ZSTLv8GZ3YSut0aL1VU7LLmiHQ1B1DQ@mail.gmail.com> 2015-09-11 21:59 ` Paul E. McKenney 2015-09-11 21:59 ` Paul E. McKenney 2015-09-12 5:46 ` Boqun Feng 2015-09-21 19:30 ` Frederic Weisbecker 2015-09-21 19:30 ` Frederic Weisbecker 2015-09-21 20:43 ` Paul E. McKenney 2015-09-21 20:43 ` Paul E. McKenney 2019-06-02 5:56 ` rcu_read_lock lost its compiler barrier Herbert Xu 2019-06-02 5:56 ` Herbert Xu 2019-06-02 20:54 ` Linus Torvalds 2019-06-02 20:54 ` Linus Torvalds 2019-06-03 2:46 ` Herbert Xu 2019-06-03 2:46 ` Herbert Xu 2019-06-03 3:47 ` Paul E. McKenney 2019-06-03 4:01 ` Herbert Xu 2019-06-03 4:01 ` Herbert Xu 2019-06-03 4:17 ` Herbert Xu 2019-06-03 4:17 ` Herbert Xu 2019-06-03 7:23 ` Paul E. McKenney 2019-06-03 8:42 ` Paul E. McKenney 2019-06-03 15:26 ` David Laight 2019-06-03 15:40 ` Linus Torvalds 2019-06-03 15:40 ` Linus Torvalds 2019-06-03 5:26 ` Herbert Xu 2019-06-03 5:26 ` Herbert Xu 2019-06-03 6:42 ` Boqun Feng 2019-06-03 6:42 ` Boqun Feng 2019-06-03 20:03 ` Paul E. McKenney 2019-06-04 14:44 ` Alan Stern 2019-06-04 14:44 ` Alan Stern 2019-06-04 16:04 ` Linus Torvalds 2019-06-04 16:04 ` Linus Torvalds 2019-06-04 17:00 ` Alan Stern 2019-06-04 17:00 ` Alan Stern 2019-06-04 17:29 ` Linus Torvalds 2019-06-04 17:29 ` Linus Torvalds 2019-06-07 14:09 ` inet: frags: Turn fqdir->dead into an int for old Alphas Herbert Xu 2019-06-07 14:09 ` Herbert Xu 2019-06-07 15:26 ` Eric Dumazet 2019-06-07 15:26 ` Eric Dumazet 2019-06-07 15:32 ` Herbert Xu 2019-06-07 15:32 ` Herbert Xu 2019-06-07 16:13 ` Eric Dumazet 2019-06-07 16:13 ` Eric Dumazet 2019-06-07 16:19 ` Linus Torvalds 2019-06-07 16:19 ` Linus Torvalds 2019-06-08 15:27 ` Paul E. McKenney 2019-06-08 17:42 ` Linus Torvalds 2019-06-08 17:42 ` Linus Torvalds 2019-06-08 17:50 ` Linus Torvalds 2019-06-08 17:50 ` Linus Torvalds 2019-06-08 18:50 ` Paul E. McKenney 2019-06-08 18:14 ` Paul E. McKenney 2019-06-06 4:51 ` rcu_read_lock lost its compiler barrier Herbert Xu 2019-06-06 4:51 ` Herbert Xu 2019-06-06 6:05 ` Paul E. McKenney 2019-06-06 6:14 ` Herbert Xu 2019-06-06 6:14 ` Herbert Xu 2019-06-06 9:06 ` Paul E. McKenney 2019-06-06 9:28 ` Herbert Xu 2019-06-06 9:28 ` Herbert Xu 2019-06-06 10:58 ` Paul E. McKenney 2019-06-06 13:38 ` Herbert Xu 2019-06-06 13:38 ` Herbert Xu 2019-06-06 13:48 ` Paul E. McKenney 2019-06-06 8:16 ` Andrea Parri 2019-06-06 14:19 ` Alan Stern 2019-06-06 14:19 ` Alan Stern 2019-06-08 15:19 ` Paul E. McKenney 2019-06-08 15:56 ` Alan Stern 2019-06-08 15:56 ` Alan Stern 2019-06-08 16:31 ` Paul E. McKenney 2019-06-03 9:35 ` Paul E. McKenney 2019-06-06 8:38 ` Andrea Parri 2019-06-06 9:32 ` Herbert Xu 2019-06-06 9:32 ` Herbert Xu 2019-06-03 0:06 ` Paul E. McKenney 2019-06-03 3:03 ` Herbert Xu 2019-06-03 3:03 ` Herbert Xu 2019-06-03 9:27 ` Paul E. McKenney 2019-06-03 15:55 ` Linus Torvalds 2019-06-03 15:55 ` Linus Torvalds 2019-06-03 16:07 ` Linus Torvalds 2019-06-03 16:07 ` Linus Torvalds 2019-06-03 19:53 ` Paul E. McKenney 2019-06-03 20:24 ` Linus Torvalds [this message] 2019-06-03 20:24 ` Linus Torvalds 2019-06-04 21:14 ` Paul E. McKenney 2019-06-05 2:21 ` Herbert Xu 2019-06-05 2:21 ` Herbert Xu 2019-06-05 3:30 ` Paul E. McKenney 2019-06-06 4:37 ` Herbert Xu 2019-06-06 4:37 ` Herbert Xu
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-=whXb-QGZqOZ7S9YdjvQf7FNymzceinzJegvRALqXm3=FQ@mail.gmail.com' \ --to=torvalds@linux-foundation.org \ --cc=boqun.feng@gmail.com \ --cc=davem@davemloft.net \ --cc=fengguang.wu@intel.com \ --cc=fweisbec@gmail.com \ --cc=herbert@gondor.apana.org.au \ --cc=linux-kernel@vger.kernel.org \ --cc=lkp@01.org \ --cc=netdev@vger.kernel.org \ --cc=paulmck@linux.ibm.com \ /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: linkBe 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.