[Bug 299418] After the FreeBSD-SA-26:71.sound update loading the multimedia/cx88 driver causes a kernel panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=299418

Jason A. Harmening <jah@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |christos@freebsd.org

--- Comment #4 from Jason A. Harmening <jah@FreeBSD.org> ---
I'll try to create a local repro as soon as I can get in front of the right
machine.

I think part of the reason for the panic may actually be that recent-ish
sound(4) changes seem to make it more difficult to properly clean up from an
intermediate failure like the one seen here.

Prior to
https://cgit.freebsd.org/src/commit/sys/dev/sound/pcm/?id=3107b952f534813846e4f58afdb57624a81618d8,
pcm_unregister() was only gated on PCM_ALIVE(), so as long as pcm_init() had
previously been called it would proceed to tear down all channels, uninit the
mixer, etc.  So if a driver executed a call sequence like
pcm_init()/mixer_init()/pcm_addchan()/pcm_register() and encountered an error
in one of the intermediate steps, in theory it only needed to call
pcm_unregister() to properly clean up.  Some of the in-tree sound drivers
appear to be written with this assumption.

Now that pcm_unregister() is gated on PCM_REGISTERED(), it won't do anything
unless pcm_register() has already been called, so if a driver hits an error
before calling pcm_register() and tries to clean up using pcm_unregister() it
may end up leaking a bunch of resources and potentially running into the mixer
reinit panic seen here.

It may be that the recommended sequence these days is to call pcm_register()
even if an earlier step fails, but if so that should probably be documented
somewhere and made consistent in-tree.

-- 
You are receiving this mail because:
You are on the CC list for the bug.