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: <219114011.864.1547101805680.JavaMail.zimbra@efficios.com>
Date:   Thu, 10 Jan 2019 01:30:05 -0500 (EST)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     paulmck <paulmck@...ux.ibm.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        rostedt <rostedt@...dmis.org>
Subject: Re: Possible use of RCU while in extended QS: idle vs RCU read-side
 in interrupt vs rcu_eqs_exit

----- On Jan 9, 2019, at 8:13 PM, paulmck paulmck@...ux.ibm.com wrote:

> On Wed, Jan 09, 2019 at 08:38:51PM -0500, Mathieu Desnoyers wrote:
>> Hi Paul,
>> 
>> I've had a user report that trace_sched_waking() appears to be
>> invoked while !rcu_is_watching() in some situation, so I started
>> digging into the scheduler idle code.
>> 
>> It appears that interrupts are re-enabled before rcu_eqs_exit() is
>> invoked when exiting idle code from the scheduler.
>> 
>> I wonder what happens if an interrupt handler (including scheduler code)
>> happens to issue a RCU read-side critical section before rcu_eqs_exit()
>> is called ? Is there some code on interrupt entry that ensures rcu eqs
>> state is exited in such scenario ?
> 
> Interrupt handlers are supposed to invoke irq_enter(), which will in
> turn invoke rcu_irq_enter(), which should take care of things.
> 
> However, there are cases where a given architecture knows that a given
> interrupt handler does not contain RCU readers, and in this case, the
> architecture might omit the rcu_irq_enter() or maybe even the whole
> irq_enter().  And then it is all fun and games until someone adds an
> RCU read-side critical section.  ;-)

Even if an irq handler does not contain any RCU read-side critical
section, won't it end by possibly invoking the scheduler before
returning ? Considering that the scheduler has tracepoints which
use RCU, this might be related to the issue that has been brought
to my attention.

Do you have examples of such interrupt handlers which do not invoke
rcu_irq_enter() ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ