linux-kernel - Re: [RFC PATCH RT 3/4] rcu: unlock special: Treat irq and preempt disabled the same

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20190622002606.GL26519@linux.ibm.com>
Date:   Fri, 21 Jun 2019 17:26:06 -0700
From:   "Paul E. McKenney" <paulmck@...ux.ibm.com>
To:     Scott Wood <swood@...hat.com>
Cc:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Juri Lelli <juri.lelli@...hat.com>,
        Clark Williams <williams@...hat.com>,
        linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH RT 3/4] rcu: unlock special: Treat irq and preempt
 disabled the same

On Thu, Jun 20, 2019 at 06:08:19PM -0500, Scott Wood wrote:
> On Thu, 2019-06-20 at 15:25 -0700, Paul E. McKenney wrote:
> > On Thu, Jun 20, 2019 at 04:59:30PM -0500, Scott Wood wrote:
> > > On Thu, 2019-06-20 at 14:10 -0700, Paul E. McKenney wrote:
> > > > On Tue, Jun 18, 2019 at 08:19:07PM -0500, Scott Wood wrote:
> > > > > [Note: Just before posting this I noticed that the invoke_rcu_core
> > > > > stuff
> > > > >  is part of the latest RCU pull request, and it has a patch that
> > > > >  addresses this in a more complicated way that appears to deal with
> > > > > the
> > > > >  bare irq-disabled sequence as well.
> > > > 
> > > > Far easier to deal with it than to debug the lack of it.  ;-)
> > > > 
> > > > >  Assuming we need/want to support such sequences, is the
> > > > >  invoke_rcu_core() call actually going to result in scheduling any
> > > > >  sooner?  resched_curr() just does the same setting of need_resched
> > > > >  when it's the same cpu.
> > > > > ]
> > > > 
> > > > Yes, invoke_rcu_core() can in some cases invoke the scheduler sooner.
> > > > Setting the CPU-local bits might not have effect until the next
> > > > interrupt.
> > > 
> > > Maybe I'm missing something, but I don't see how (in the non-use_softirq
> > > case).  It just calls wake_up_process(), which in resched_curr() will
> > > set
> > > need_resched but not do an IPI-to-self.
> > 
> > The common non-rt case will be use_softirq.  Or are you referring
> > specifically to this block of code in current -rcu?
> > 
> > 		} else if (exp && irqs_were_disabled && !use_softirq &&
> > 			   !t->rcu_read_unlock_special.b.deferred_qs) {
> > 			// Safe to awaken and we get no help from enabling
> > 			// irqs, unlike bh/preempt.
> > 			invoke_rcu_core();
> 
> Yes, that one.  If that block is removed the else path should be sufficient,
> now that an IPI-to-self has been added.

I will give it a try and let you know what happens.

> Also, shouldn't the IPI-to-self be conditioned on irqs_were_disabled? 
> Besides that being the problem the IPI was meant to address, if irqs are
> enabled the IPI is likely to happen before preempt is re-enabled and thus it
> won't accomplish anything.

Plus if preempt is disabled, the later preempt_enable() will check
(ditto for local_bh_enable()).  Unless the preempt_enable() is instead
a preempt_enable_no_resched(), of course.  :-/

							Thanx, Paul