linux-kernel - Re: Possible use of RCU while in extended QS: idle vs RCU read-side in interrupt vs rcu_eqs

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