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: <878qiutsdu.wl-tiwai@suse.de>
Date: Thu, 04 Sep 2025 12:38:05 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: 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: [syzbot] [sound?] possible deadlock in __snd_pcm_lib_xfer (2)

On Thu, 04 Sep 2025 12:20:56 +0200,
Sebastian Andrzej Siewior wrote:
> 
> On 2025-08-29 17:06:02 [-0700], syzbot wrote:
> > syzbot has bisected this issue to:
> > 
> > commit d2d6422f8bd17c6bb205133e290625a564194496
> > Author: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> > Date:   Fri Sep 6 10:59:04 2024 +0000
> > 
> >     x86: Allow to enable PREEMPT_RT.
> > 
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=12db5634580000
> > start commit:   07d9df80082b Merge tag 'perf-tools-fixes-for-v6.17-2025-08..
> > git tree:       upstream
> > final oops:     https://syzkaller.appspot.com/x/report.txt?x=11db5634580000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=16db5634580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=e1e1566c7726877e
> > dashboard link: https://syzkaller.appspot.com/bug?extid=10b4363fb0f46527f3f3
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10307262580000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17110242580000
> > 
> > Reported-by: syzbot+10b4363fb0f46527f3f3@...kaller.appspotmail.com
> > Fixes: d2d6422f8bd1 ("x86: Allow to enable PREEMPT_RT.")
> 
> This is unfortunate. There is nothing that sound did wrong, it is rather
> special softirq handling in this case. We don't see this often because
> it requires that a timer is cancelled at the time it is running.
> The assumption made by sound is that spin_lock_irq() also disables
> softirqs. This is not the case on PREEMPT_RT.
> 
> The hunk below avoids the splat. Adding local_bh_disable() to
> spin_lock_irq() would cure it, too. It would also result in random
> synchronisation points across the kernel leading to something less
> usable.
> The imho best solution would to get rid of softirq_ctrl.lock which has
> been proposed
> 	https://lore.kernel.org/all/20250901163811.963326-4-bigeasy@linutronix.de/
> 
> Comments?

Thank you for the detailed analysis!  It enlightened me.

It'd be appreciated if this gets fixed in the softirq core side.
If nothing else flies, we can take your workaround, sure...


Takashi

> 
> diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
> --- a/sound/core/pcm_native.c
> +++ b/sound/core/pcm_native.c
> @@ -84,19 +84,24 @@ void snd_pcm_group_init(struct snd_pcm_group *group)
>  }
>  
>  /* define group lock helpers */
> -#define DEFINE_PCM_GROUP_LOCK(action, mutex_action) \
> +#define DEFINE_PCM_GROUP_LOCK(action, bh_lock, bh_unlock, mutex_action) \
>  static void snd_pcm_group_ ## action(struct snd_pcm_group *group, bool nonatomic) \
>  { \
> -	if (nonatomic) \
> +	if (nonatomic) { \
>  		mutex_ ## mutex_action(&group->mutex); \
> -	else \
> -		spin_ ## action(&group->lock); \
> +	} else { \
> +		if (IS_ENABLED(CONFIG_PREEMPT_RT) && bh_lock)	\
> +			local_bh_disable();			\
> +		spin_ ## action(&group->lock);			\
> +		if (IS_ENABLED(CONFIG_PREEMPT_RT) && bh_unlock)	\
> +			local_bh_enable();			\
> +	}							\
>  }
>  
> -DEFINE_PCM_GROUP_LOCK(lock, lock);
> -DEFINE_PCM_GROUP_LOCK(unlock, unlock);
> -DEFINE_PCM_GROUP_LOCK(lock_irq, lock);
> -DEFINE_PCM_GROUP_LOCK(unlock_irq, unlock);
> +DEFINE_PCM_GROUP_LOCK(lock, 0, 0, lock);
> +DEFINE_PCM_GROUP_LOCK(unlock, 0, 0, unlock);
> +DEFINE_PCM_GROUP_LOCK(lock_irq, 1, 0, lock);
> +DEFINE_PCM_GROUP_LOCK(unlock_irq, 0, 1, unlock);
>  
>  /**
>   * snd_pcm_stream_lock - Lock the PCM stream
> 
> 
> Sebastian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ