linux-kernel - Re: [PATCH 1/2] lockdep: Don't disable interrupts on RT in disable_irq_nosync

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] [day] [month] [year] [list]

Message-ID: <Z7iz8I6QD9Amjfmw@Mac.home>
Date: Fri, 21 Feb 2025 09:12:16 -0800
From: Boqun Feng <boqun.feng@...il.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-rt-devel@...ts.linux.dev, linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
	Waiman Long <longman@...hat.com>,
	Guenter Roeck <linux@...ck-us.net>,
	Clark Williams <clrkwllms@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH 1/2] lockdep: Don't disable interrupts on RT in
 disable_irq_nosync_lockdep.*()

On Wed, Feb 12, 2025 at 11:36:18AM +0100, Sebastian Andrzej Siewior wrote:
> disable_irq_nosync_lockdep() disables interrupts with lockdep enabled to
> avoid false positive reports by lockdep that a certain lock has not been
> acquired with disabled interrupts. The user of this macros expects that
> a lock can be acquried without disabling interrupts because the IRQ line
> triggering the interrupt is disabled.
> 
> This triggers a warning on PREEMPT_RT because after
> disable_irq_nosync_lockdep.*() the following spinlock_t now is acquired
> with disabled interrupts.
> 
> On PREEMPT_RT there is no difference between spin_lock() and
> spin_lock_irq() so avoiding disabling interrupts in this case works for
> the two remaining callers as of today.
> 
> Don't disable interrupts on PREEMPT_RT in disable_irq_nosync_lockdep.*().
> 
> Reported-by: Guenter Roeck <linux@...ck-us.net>
> Closes: https://lore.kernel.org/760e34f9-6034-40e0-82a5-ee9becd24438@roeck-us.net
> Fixes: e8106b941ceab ("[PATCH] lockdep: core, add enable/disable_irq_irqsave/irqrestore() APIs")

Is this "Fixes" tag accurate? IIUC, the issue only exists after
CONFIG_PREEMPT_RT is introduced from mainline POV. Or we want this to be
backported in older stable kernels predating CONFIG_PREEMPT_RT?

Regards,
Boqun

> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> ---
>  include/linux/interrupt.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 8cd9327e4e78d..a1b1be9bf73b2 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -448,7 +448,7 @@ irq_calc_affinity_vectors(unsigned int minvec, unsigned int maxvec,
>  static inline void disable_irq_nosync_lockdep(unsigned int irq)
>  {
>  	disable_irq_nosync(irq);
> -#ifdef CONFIG_LOCKDEP
> +#if defined(CONFIG_LOCKDEP) && !defined(CONFIG_PREEMPT_RT)
>  	local_irq_disable();
>  #endif
>  }
> @@ -456,7 +456,7 @@ static inline void disable_irq_nosync_lockdep(unsigned int irq)
>  static inline void disable_irq_nosync_lockdep_irqsave(unsigned int irq, unsigned long *flags)
>  {
>  	disable_irq_nosync(irq);
> -#ifdef CONFIG_LOCKDEP
> +#if defined(CONFIG_LOCKDEP) && !defined(CONFIG_PREEMPT_RT)
>  	local_irq_save(*flags);
>  #endif
>  }
> @@ -471,7 +471,7 @@ static inline void disable_irq_lockdep(unsigned int irq)
>  
>  static inline void enable_irq_lockdep(unsigned int irq)
>  {
> -#ifdef CONFIG_LOCKDEP
> +#if defined(CONFIG_LOCKDEP) && !defined(CONFIG_PREEMPT_RT)
>  	local_irq_enable();
>  #endif
>  	enable_irq(irq);
> @@ -479,7 +479,7 @@ static inline void enable_irq_lockdep(unsigned int irq)
>  
>  static inline void enable_irq_lockdep_irqrestore(unsigned int irq, unsigned long *flags)
>  {
> -#ifdef CONFIG_LOCKDEP
> +#if defined(CONFIG_LOCKDEP) && !defined(CONFIG_PREEMPT_RT)
>  	local_irq_restore(*flags);
>  #endif
>  	enable_irq(irq);
> -- 
> 2.47.2
>