linux-kernel - Re: [PATCH tip/core/rcu 06/19] rcu: Add warning to detect half-interrupts

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: <20190313150948.GA84821@google.com>
Date:   Wed, 13 Mar 2019 11:09:48 -0400
From:   Joel Fernandes <joel@...lfernandes.org>
To:     "Paul E. McKenney" <paulmck@...ux.ibm.com>
Cc:     linux-kernel@...r.kernel.org, rcu@...r.kernel.org,
        jiangshanlai@...il.com, dipankar@...ibm.com,
        mathieu.desnoyers@...icios.com, josh@...htriplett.org,
        rostedt@...dmis.org, luto@...nel.org, byungchul.park@....com
Subject: Re: [PATCH tip/core/rcu 06/19] rcu: Add warning to detect
 half-interrupts

On Tue, Mar 12, 2019 at 08:20:34AM -0700, Paul E. McKenney wrote:
[snip]
> 
> >            Could we be more explicit in the code that this function can only
> > be called from an interrupt, and also we change the code comment to be more
> > clear about it (like the following diff)?
> 
> That would be good!
> 
> Nice trick on using dyntick state to check for interrupt nesting, but
> wouldn't consolidating the counters break that?  But is there a lockdep
> check for being in a hardware interrupt handler?  If not, could one
> be added?  This would have the benefit of not adding overhead to the
> scheduling-clock interrupt in production builds of the Linux kernel,
> while still finding this bug in testing.
> 
> (Another approach would be to use IS_ENABLED(CONFIG_PROVE_RCU), but
> a lockdep check would be cleaner.)

AFAICS, lockdep does not specifically track when we enter an interrupt, but
rather only tracks when interrupts are enabled/disabled.

But we could use in_irq() to find if we are in an interrupt (which uses the
preempt_count to track in HARDIRQ_MASK section of the counter).

I will add an in_irq() check that does the check only when PROVE_RCU is
enabled, and send a patch.

Thanks and it is my pleasure to look into this, quite interesting!

 - Joel