Re: [alsa-devel] unload Audio drivers while playback stream is active case kernel crash

[Takashi Iwai <tiwai@suse.de>]

At Wed, 14 Jan 2015 12:02:28 +0000,
Mark Brown wrote:
> 
> On Wed, Jan 14, 2015 at 11:50:48AM +0100, Takashi Iwai wrote:
> > Lars-Peter Clausen wrote:
> 
> > > > OK, so it's not about active stream.  From the reporter's description,
> > > > I supposed that the module gets unloaded while playing a stream, which
> > > > shouldn't be allowed.
> 
> > > Well one of the ways to trigger this is to remove the module while the 
> > > stream is active. But it is not exclusively a problem module unload problem. 
> > > E.g. the same happens if you hot-unplug the ASoC card.
> 
> > Yes, unbinding can trigger a similar problem, ends up the same bad
> > code path.
> 
> Right, which was my point - we need to be able to cope with the driver
> being removed while in use, unbind is just one path where this could
> happen and the issue isn't specific to unbind.
> 
> > > I don't think that we need to prevent module unload when a stream is active. 
> > >  From a framework point of view is not different from hot-unplug. I don't 
> > > see a reason why we'd jump through hoops to actively forbid removing the 
> > > module once it works just fine.
> 
> > Well, the module unload means a more drastic cleanup.  Even if you
> > unbind, the code and data are still there while module unload may
> > clean them up all.
> 
> > Above all, disallowing the module unload while using is the common
> > behavior of any other drivers.  Why do we have to be a rebel against
> > all civil manner? :)
> 
> That's not true for everything

Hmm, which driver does behave so intentionally?  I'm interested in the
supposed reason behind it.

> and for ASoC I'd tend to assume that the
> user knows what they're doing and has a good reason for it; it's
> certainly something that can be helpful in development.

The module unload is never considered to be equivalent with hot
unplug  It's more than that.


Takashi