From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752132AbbANNBf (ORCPT ); Wed, 14 Jan 2015 08:01:35 -0500 Received: from cantor2.suse.de ([195.135.220.15]:57254 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752086AbbANNBe (ORCPT ); Wed, 14 Jan 2015 08:01:34 -0500 Date: Wed, 14 Jan 2015 14:01:33 +0100 Message-ID: From: Takashi Iwai To: Mark Brown Cc: Lars-Peter Clausen , "alsa-devel@alsa-project.org" , "Wang, Jiada (ESD)" , "linux-kernel@vger.kernel.org" , "lgirdwood@gmail.com" , "Frkuska, Joshua" Subject: Re: [alsa-devel] unload Audio drivers while playback stream is active case kernel crash In-Reply-To: <20150114120228.GT4160@sirena.org.uk> References: <857E9EDCA6C0904DB3357321AA9123EB0108B66919@NA-MBX-01.mgc.mentorg.com> <20150113215412.GS4160@sirena.org.uk> <54B625A8.8090406@metafoo.de> <54B63E4F.2010506@metafoo.de> <20150114120228.GT4160@sirena.org.uk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.4 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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