linux-kernel - Re: [PATCH] ALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT

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: <87v7li20me.wl-tiwai@suse.de>
Date: Tue, 16 Sep 2025 11:43:53 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Takashi Iwai <tiwai@...e.de>,
	syzbot <syzbot+10b4363fb0f46527f3f3@...kaller.appspotmail.com>,
	tglx@...utronix.de,
	bp@...en8.de,
	dave.hansen@...ux.intel.com,
	hpa@...or.com,
	linux-kernel@...r.kernel.org,
	linux-sound@...r.kernel.org,
	mingo@...hat.com,
	perex@...ex.cz,
	syzkaller-bugs@...glegroups.com,
	tiwai@...e.com,
	x86@...nel.org
Subject: Re: [PATCH] ALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT_RT

On Mon, 15 Sep 2025 17:28:51 +0200,
Sebastian Andrzej Siewior wrote:
> 
> snd_pcm_group_lock_irq() acquires a spinlock_t and disables interrupts
> via spin_lock_irq(). This also implicitly disables the handling of
> softirqs such as TIMER_SOFTIRQ.
> On PREEMPT_RT softirqs are preemptible and spin_lock_irq() does not
> disable them. That means a timer can be invoked during spin_lock_irq()
> on the same CPU. Due to synchronisations reasons local_bh_disable() has
> a per-CPU lock named softirq_ctrl.lock which synchronizes individual
> softirq against each other.
> syz-bot managed to trigger a lockdep report where softirq_ctrl.lock is
> acquired in hrtimer_cancel() in addition to hrtimer_run_softirq(). This
> is a possible deadlock.
> 
> The softirq_ctrl.lock can not be made part of spin_lock_irq() as this
> would lead to too much synchronisation against individual threads on the
> system. To avoid the possible deadlock, softirqs must be manually
> disabled before the lock is acquired.
> 
> Disable softirqs before the lock is acquired on PREEMPT_RT.
> 
> Reported-by: syzbot+10b4363fb0f46527f3f3@...kaller.appspotmail.com
> Fixes: d2d6422f8bd1 ("x86: Allow to enable PREEMPT_RT.")
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> ---
> 
> I don't see a way around this given the report. I don't see how to
> address this within the softirq. Taking this lock as part of every
> spin_lock_irq() would be a mess and while testing I didn't even manage
> to boot the machine. So I probably missed a detail (but then I would
> only know how mad it really is).
> 
> This can be an intermediate solution until
> 	https://lore.kernel.org/all/20250901163811.963326-4-bigeasy@linutronix.de/
> 
> gets merged and the !PREEMPT_RT_NEEDS_BH_LOCK case the default (i.e. not
> a config option anymore).

I applied now to for-next branch for 6.18.
It's already at a late stage for 6.17 release, and the issue doesn't
seem like an urgent regression to be fixed.


Thanks!

Takashi