On Thu, Mar 05, 2020 at 03:06:17PM +0100, Amadeusz Sławiński wrote: > On 3/5/2020 2:47 PM, Pierre-Louis Bossart wrote: > > It's probably because the devm_ release does not happen when the card is > > unregistered and the machine driver resources released since we use the > > component device. There might very well be a bug somewhere in the devm_ > > handling, I just don't have a clue how to debug this - and the .exit() > > makes sense regardless in other cases unrelated to GPIOs. > This sounds related to issue I've seen related to fact that there is > devm_snd_soc_register_component and devm_snd_soc_register_card and when > cleanup happens, one of them seems to release memory before other one runs > it cleanup functions. And then cleanup functions try to operate on already > released memory. > I haven't debugged this in depth, and just made simple patch to replace > problematic devm_kzalloc with kzalloc and kfree, but there seems something > weird happening related to how dynamic memory management works in ASOC. There's definitely an issue if you mix devm and non-devm stuff (see also the frequent issues with devm_request_irq()). The devm stuff only gets unwound after the remove callback has executed so if you free stuff in the remove callback that you will rely on in the devm cleanup operations then there's issues. The devm stuff will also always get unwound in the opposite order to that which it was allocated which usually isn't a problem but can be worth paying attention to.
Attachment:
signature.asc
Description: PGP signature
