snd_uaudio: Do not use pcm_channel->lock to protect uaudio_chan
ClosedPublic
Actions

Authored by christos on Dec 6 2025, 2:52 PM.

Details

Reviewers

markj
emaste

Commits

rGf3092142f9ba: snd_uaudio: Do not use pcm_channel->lock to protect uaudio_chan
rGc234740c9d34: snd_uaudio: Do not use pcm_channel->lock to protect uaudio_chan

Summary

This is a layering violation, but it also makes the control flow
confusing; snd_uaudio(4) should have its own lock to protect its
structures.

Fixes: 5cc34a83e1 ("Revert "sound: Merge chn_intr() with chn_intr_locked()"")
Sponsored by: The FreeBSD Foundation
MFC after: 1 week

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

christos created this revision.Dec 6 2025, 2:52 PM

Herald added a subscriber: imp. · View Herald TranscriptDec 6 2025, 2:52 PM

christos requested review of this revision.Dec 6 2025, 2:52 PM

Harbormaster completed remote builds in B69100: Diff 167647.Dec 6 2025, 2:52 PM

What problem does this fix?

In D54102#1236568, @markj wrote:

What problem does this fix?

From the commit referenced in "Fixes" (5cc34a83e1):

It turns out that snd_uaudio(4) uses sound(4)'s channel lock for its USB
transfer callbacks. I will try to address this at some point, because
this is layering violation, but for now we need to revert the commit, as
it causes a lock recursion panic with USB audio devices.

In D54102#1236569, @christos wrote:

In D54102#1236568, @markj wrote:

What problem does this fix?

From the commit referenced in "Fixes" (5cc34a83e1):

It turns out that snd_uaudio(4) uses sound(4)'s channel lock for its USB
transfer callbacks. I will try to address this at some point, because
this is layering violation, but for now we need to revert the commit, as
it causes a lock recursion panic with USB audio devices.