linux-kernel - Re: [RFC v2] rcu/tree: Try to invoke_rcu_core() if in

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: <20190821154646.GG147977@google.com>
Date:   Wed, 21 Aug 2019 11:46:46 -0400
From:   Joel Fernandes <joel@...lfernandes.org>
To:     "Paul E. McKenney" <paulmck@...ux.ibm.com>
Cc:     linux-kernel@...r.kernel.org,
        Josh Triplett <josh@...htriplett.org>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        rcu@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [RFC v2] rcu/tree: Try to invoke_rcu_core() if in_irq() during
 unlock

On Wed, Aug 21, 2019 at 08:39:57AM -0700, Paul E. McKenney wrote:
> On Wed, Aug 21, 2019 at 10:56:17AM -0400, Joel Fernandes wrote:
[snip]
> > I think one reason could be, in_irq() is false when the timer callback
> > executes, since the timer callback is executing after a grace-period. The
> > stack is as follows:
> > 
> > Any reason why we cannot both test for call_rcu() and execute the RCU
> > callback from the timer hardirq handler?
> > 
> > In fact, I guess on use_nosoftirq systems, the callback will not even run
> > in softirq context.
> > 
> > [   20.553361]  => rcu_torture_timer_cb
> > [   20.553361]  => rcu_do_batch
> > [   20.553361]  => rcu_core
> > [   20.553361]  => __do_softirq
> > [   20.553361]  => do_softirq_own_stack
> > [   20.553361]  => do_softirq.part.16
> > [   20.553361]  => __local_bh_enable_ip
> > [   20.553361]  => rcutorture_one_extend
> > [   20.553361]  => rcu_torture_one_read
> > [   20.553361]  => rcu_torture_reader
> > [   20.553361]  => kthread
> > [   20.553361]  => ret_from_fork
> 
> Well, it is rcu_read_lock() and rcu_read_unlock() that matters

True!

> for this case rather than the callback.  But yes, given in_irq(),
> rcu_read_lock() and rcu_read_unlock() would need to have executed
> from a hardware interrupt handler.  And would need to get one of the
> ->rcu_read_lock_special bits set somehow.
> 
> But you can use smp_call_function() to invoke a function that runs in
> hardware interrupt handler context, and you can do this within either
> rcuperf or rcutorture.
> 
> And yes, this line of reasoning did inform at least some of my skepticism
> surrounding your initial patch, in case you were wondering about some
> of my earlier questions.  ;-)

Sounds great, I will try to modify the tests to trigger this case and also
look into your other questions. Thanks!!

 - Joel