linux-kernel - Re: [PATCH RFC] doc: rcu: remove obsolete (non-)requirement about disabling preemption

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20181018225223.42641c73@vmware.local.home>
Date:   Thu, 18 Oct 2018 22:52:23 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Joel Fernandes <joel@...lfernandes.org>
Cc:     "Paul E. McKenney" <paulmck@...ux.ibm.com>,
        Nikolay Borisov <nborisov@...e.com>,
        linux-kernel@...r.kernel.org, Jonathan Corbet <corbet@....net>,
        Josh Triplett <josh@...htriplett.org>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        linux-doc@...r.kernel.org,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: [PATCH RFC] doc: rcu: remove obsolete (non-)requirement about
 disabling preemption

On Thu, 18 Oct 2018 19:25:29 -0700
Joel Fernandes <joel@...lfernandes.org> wrote:

> On Thu, Oct 18, 2018 at 09:50:35PM -0400, Steven Rostedt wrote:
> > On Thu, 18 Oct 2018 18:26:45 -0700
> > Joel Fernandes <joel@...lfernandes.org> wrote:
> >   
> > > Yes, local_irq_restore is light weight, and does not check for reschedules.
> > > 
> > > I was thinking of case where ksoftirqd is woken up, but does not run unless
> > > we set the NEED_RESCHED flag. But that should get set anyway since probably
> > > ksoftirqd is of high enough priority than the currently running task..
> > > 
> > > Roughly speaking the scenario could be something like:
> > > 
> > > rcu_read_lock();
> > >                  <-- IPI comes in for the expedited GP, sets exp_hint
> > > local_irq_disable();
> > > // do a bunch of stuff
> > > rcu_read_unlock();   <-- This calls the rcu_read_unlock_special which raises
> > >                          the soft irq, and wakesup softirqd.  
> > 
> > If softirqd is of higher priority than the current running task, then
> > the try_to_wake_up() will set NEED_RESCHED of the current task here.
> >   
> 
> Yes, only *if*. On my system, ksoftirqd is CFS nice 0. I thought expedited
> grace periods are quite important and they should complete quickly which is
> the whole reason for interrupting rcu read sections with an IPI and stuff.
> IMO there should be no harm in setting NEED_RESCHED unconditionally anyway
> for possible benefit of systems where the ksoftirqd is not of higher priority
> than the currently running task, and we need to run it soon on the CPU. But
> I'm Ok with whatever Paul and you want to do here.


Setting NEED_RESCHED unconditionally wont help. Because even if we call
schedule() ksoftirqd will not be scheduled! If it's CFS nice 0, and the
current task still has quota to run, if you call schedule, you'll just
waste time calculating that the current task should still be running.
It's equivalent to calling yield() (which is why we removed all yield()
users in the kernel, because *all* of them were buggy!). This is *why*
it only calls schedule *if* softirqd is of higher priority.

-- Steve