Page MenuHomeFreeBSD

sound: Revalidate after reacquiring locks when resizing buffers
Needs ReviewPublic

Authored by markj on Fri, Oct 9, 9:14 PM.
Tags
None
Referenced Files
F175332563: D60554.id189297.diff
Sat, Oct 10, 1:28 AM
F175332427: D60554.diff
Sat, Oct 10, 1:26 AM
F175332325: D60554.id189305.diff
Sat, Oct 10, 1:25 AM
F175327051: D60554.id189297.diff
Sat, Oct 10, 12:17 AM
F175327007: D60554.id.diff
Sat, Oct 10, 12:16 AM
F175326956: D60554.id189305.diff
Sat, Oct 10, 12:15 AM
F175326944: D60554.diff
Sat, Oct 10, 12:15 AM
F175317517: D60554.id189297.diff
Fri, Oct 9, 10:12 PM
Subscribers

Details

Reviewers
kib
christos
Summary

sndbuf_resize() and sndbuf_remalloc() drop the channel lock in order to
allocate the new buffer(s) with M_WAITOK. Before doing that they verify
that the buffer is not mapped, but this could change while the lock is
dropped, as there is no higher-level synchronization which prevents
buffer resize (e.g., via the SNDCTL_DSP_SETBLKSIZE ioctl) from happening
concurrently with mmap. Thus, these checks are insufficient.

Modify sndbuf_resize() and sndbuf_remalloc() to revalidate after
reacquiring the lock. Extend them to check for a couple of channel
flags, mirroring the check in chn_resizebuf(). Modify chn_resizebuf()
to revalidate state after reacquiring the channel lock.

We could also allocate new buffers with M_NOWAIT and so avoid dropping
the lock. Then, I think we could go even further and invoke
CHANNEL_SETBLOCKSIZE and CHANNEL_SETFRAGMENTS with the channel lock
held. But really it would be better to ensure that dsp operations are
serialized; there is no reason for mmap and chn_resizebuf() to be able
to run in parallel, we should not be relying on the channel lock for
this. So, let's keep a more minimal approach here.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 77929
Build 74812: arc lint + arc unit