[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
closing pad(4) before audio(4) causes panic
Closing /dev/pad before closing /dev/audio causes panic.
It is filed as PR kern/54427. It can be reproduced with attached
sample code on -current and netbsd-9.
Would someone take look?
calls audiodetach() (via config_detach_children())
-> this detaches audio device (without closing descriptors).
then calls pad_detach()
-> this detaches pad device.
panics. Because it cannot acquire mutex (sc->sc_lock). This mutex
is provided by pad, and the pad has already been detached.
According to audio.c comment, vdevgone() calls close(). But it is
not called actually.
1224 audiodetach(device_t self, int flags)
1258 * Nuke the vnodes for any open instances (calls close).
1259 * Will wait until any activity on the device nodes has ceased.
1261 mn = device_unit(self);
1262 vdevgone(maj, mn | SOUND_DEVICE, mn | SOUND_DEVICE, VCHR);
1263 vdevgone(maj, mn | AUDIO_DEVICE, mn | AUDIO_DEVICE, VCHR);
1264 vdevgone(maj, mn | AUDIOCTL_DEVICE, mn | AUDIOCTL_DEVICE, VCHR);
1265 vdevgone(maj, mn | MIXER_DEVICE, mn | MIXER_DEVICE, VCHR);
# By the way, this panic didn't occur until merging isaki-audio2.
# Because previous audio driver aborted audioclose() without refering
# this destroyed mutex (that is, it had a resource leak). In result,
# you had never encountered this panic before.
Tetsuya Isaki <isaki%pastel-flower.jp@localhost / isaki%NetBSD.org@localhost>
int main(int ac, char *av)
const char *devaudio = "/dev/audio1"; /* set your device */
fdpad = open("/dev/pad", O_RDONLY);
if (fdpad == -1)
err(1, "open: dev/pad");
fdaudio = open(devaudio, O_WRONLY);
if (fdaudio == -1)
err(1, "open: dev/audio");
Main Index |
Thread Index |