All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boqun Feng <boqun.feng@gmail.com>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	"Paul E . McKenney" <paulmck@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Uladzislau Rezki <urezki@gmail.com>,
	Ingo Molnar <mingo@kernel.org>,
	Neeraj Upadhyay <neeraju@codeaurora.org>,
	Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 2/2] rcu: Remove needless preemption disablement in rcu_all_qs()
Date: Tue, 6 Jul 2021 21:28:38 +0800	[thread overview]
Message-ID: <YORahrFT56utjlc/@boqun-archlinux> (raw)
In-Reply-To: <20210706123058.GB107277@lothringen>

On Tue, Jul 06, 2021 at 02:30:58PM +0200, Frederic Weisbecker wrote:
> On Tue, Jul 06, 2021 at 09:51:01AM +0200, Peter Zijlstra wrote:
> > On Tue, Jul 06, 2021 at 01:43:44AM +0200, Frederic Weisbecker wrote:
> > > The preemption is already disabled when we write rcu_data.rcu_urgent_qs.
> > > We can use __this_cpu_write() directly, although that path is mostly
> > > used when CONFIG_PREEMPT=n.
> > > 
> > > Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> > > Cc: Neeraj Upadhyay <neeraju@codeaurora.org>
> > > Cc: Joel Fernandes <joel@joelfernandes.org>
> > > Cc: Uladzislau Rezki <urezki@gmail.com>
> > > Cc: Boqun Feng <boqun.feng@gmail.com>
> > > ---
> > >  kernel/rcu/tree_plugin.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> > > index 27b74352cccf..38b3d01424d7 100644
> > > --- a/kernel/rcu/tree_plugin.h
> > > +++ b/kernel/rcu/tree_plugin.h
> > > @@ -871,7 +871,7 @@ void rcu_all_qs(void)
> > >  		preempt_enable();
> > >  		return;
> > >  	}
> > > -	this_cpu_write(rcu_data.rcu_urgent_qs, false);
> > > +	__this_cpu_write(rcu_data.rcu_urgent_qs, false);
> > 
> > There's another subtle difference between this_cpu_write() and
> > __this_cpu_write() aside from preempt. this_cpu_write() is also
> > IRQ-safe, while __this_cpu_write() is not.
> > 
> > I've not looked at the usage here to see if that is relevant, but the
> > Changelog only mentioned the preempt side of things, and that argument
> > is incomplete in general.
> 
> You're right, I missed that. I see this rcu_urgent_qs is set by
> RCU TASKS from rcu_tasks_wait_gp() (did I missed another path?).
> Not sure if this is called from IRQ nor if it actually matters to
> protect against IRQs for that single write.

I think __this_cpu_write() being IRQ-unsafe means it may overwrite
percpu writes to other bytes in the same word? Let's say the
rcu_urgent_qs is the lowest byte in the word, the pseduo asm code of
__this_cpu_write() may be:

	__this_cpu_write(ptr, v):
		long tmp = *ptr;
		tmp &= ~(0xff);
		tmp |= v;
		*ptr = tmp;

and the following sequence introduces an overwrite:

	__this_cpu_write(ptr, v): // v is 0, and *ptr is 1
		long tmp = *ptr; // tmp is 1
		<interrupted>
		this_cpu_write() // modify another byte of *ptr, make it
				 // 0xff01
		<ret from interrupt>
		tmp &= ~(0xff) // tmp is 0
		tmp |=v;       // tmp is 0
		*ptr = tmp;    // *ptr is 0, overwrite a percpu write on
			       // another field.

I know that many archs have byte-wise store, so compilers don't really
have the reason to generate code as above, but __this_cpu_write() is
just a normal write, nothing prevents this from happenning, unless I'm
missing something here?

Regards,
Boqun

> 
> I'm not quite used to rcu_tasks. Paul?

  reply	other threads:[~2021-07-06 13:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-05 23:43 [PATCH 1/2] rcu: Explain why rcu_all_qs() is a stub in preemptible TREE RCU Frederic Weisbecker
2021-07-05 23:43 ` [PATCH 2/2] rcu: Remove needless preemption disablement in rcu_all_qs() Frederic Weisbecker
2021-07-06  7:51   ` Peter Zijlstra
2021-07-06 12:30     ` Frederic Weisbecker
2021-07-06 13:28       ` Boqun Feng [this message]
2021-07-06 16:24         ` Paul E. McKenney
2021-07-06 16:46 ` [PATCH 1/2] rcu: Explain why rcu_all_qs() is a stub in preemptible TREE RCU 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=YORahrFT56utjlc/@boqun-archlinux \
    --to=boqun.feng@gmail.com \
    --cc=frederic@kernel.org \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=neeraju@codeaurora.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=urezki@gmail.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: 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.