On Thu, Nov 06, 2025 at 03:57:33PM -0800, Barry K. Nathan wrote:
On 11/6/25 06:30, Sasha Levin wrote:
On Thu, Nov 06, 2025 at 12:49:37AM -0800, Barry K. Nathan wrote:
On 10/25/25 08:54, Sasha Levin wrote:
From: Takashi Iwai tiwai@suse.de
[ Upstream commit 1f9fc89cbbe8a7a8648ea2f827f7d8590e62e52c ]
snd_seq_fifo_poll_wait() evaluates f->cells without locking after poll_wait(), and KCSAN doesn't like it as it appears to be a data-race. Although this doesn't matter much in practice as the value is volatile, it's still better to address it for the mind piece.
Wrap it with f->lock spinlock for avoiding the potential data race.
Reported-by: syzbot+c3dbc239259940ededba@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=c3dbc239259940ededba Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Sasha Levin sashal@kernel.org
LLM Generated explanations, may be completely bogus:
YES
- The only runtime change wraps the `f->cells` check in
`snd_seq_fifo_poll_wait()` with `guard(spinlock_irq)(&f->lock)` (`sound/core/seq/seq_fifo.c:213`), aligning this reader with every writer of `f->cells`, each of which already holds `f->lock` via `scoped_guard(spinlock_irqsave)` or explicit `spin_lock_irqsave` (`sound/core/seq/seq_fifo.c:125`, `sound/core/seq/seq_fifo.c:183`). That removes the unlocked load which KCSAN flagged as a real data race on the non-atomic `int` counter.
- This race is user-visible: if `snd_seq_fifo_poll_wait()` races with a
concurrent producer/consumer, the poll mask built in `snd_seq_poll()` (`sound/core/seq/seq_clientmgr.c:1092-1106`) can sporadically omit `EPOLLIN`, leaving sequencer clients to sleep despite queued events. On weakly ordered architectures that behavior is not just theoretical; racing non-atomic accesses are undefined in the kernel memory model and trigger syzbot reports.
- The fix is minimal, self-contained, and mirrors existing guard usage
in this file, so it has negligible regression risk: the lock is already part of the FIFO hot path, RAII unlock occurs immediately on return, and there are no new dependencies or API changes.
- Because the bug allows incorrect poll readiness and trips KCSAN, it
meets stable criteria (user-visible correctness plus sanitizer warning) and applies cleanly to older trees that already contain the guard helpers used elsewhere in this file.
Suggested next step: run the targeted ALSA sequencer poll tests (or reproducer from the linked syzbot report) on the backport branch to confirm the warning disappears.
sound/core/seq/seq_fifo.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/core/seq/seq_fifo.c b/sound/core/seq/seq_fifo.c index 3a10b081f129c..7dc2bd94cefc3 100644 --- a/sound/core/seq/seq_fifo.c +++ b/sound/core/seq/seq_fifo.c @@ -213,6 +213,7 @@ int snd_seq_fifo_poll_wait(struct snd_seq_fifo *f, struct file *file, poll_table *wait) { poll_wait(file, &f->input_sleep, wait); + guard(spinlock_irq)(&f->lock); return (f->cells > 0); }
With CONFIG_WERROR enabled, 5.15.y fails to build for me now, and it seems to be due to this patch introducing a new warning. This is with Debian bookworm and its default gcc (12.2), building for amd64. I didn't try building 6.12.y or 6.17.y yet, but this warning does not happen on 6.1.y, 6.6.y, or 6.18-rc4.
Have you manually applied this patch on top of 5.15? This patch isn't in any released LTS kernel.
Yes, I cloned the stable-queue git repo then applied the queue-5.15 patches on top of 5.15.196. I figured I'd do some testing and try to find and report problems prior to release. Once I ran into this problem, I looked into it further and narrowed it down to this patch, then I searched the stable mailing list archive to see if anyone else reported it already or if the patch had been posted to the list. The only relevant email I found was the patch itself, so that's what I replied to.
If I made any mistakes in how I reported this, or if I jumped the gun and should've waited until 5.15.197-rc1 before reporting anything, please let me know. (Maybe I should have explicitly mentioned that the patch is present in the queue as "alsa-seq-fix-kcsan-data-race-warning-at-snd_seq_fifo.patch"?)
No, you did all the right things, it just so very rare to see that :)
I've dropped that patch from all branches.
Thanks for your review!