[PATCH v4] ALSA: core: Fix deadlock when shutdown a frozen userspace

Kai Vehmanen kai.vehmanen at linux.intel.com
Tue Nov 29 13:11:34 CET 2022


Hi

On Tue, 29 Nov 2022, Takashi Iwai wrote:

> On Mon, 28 Nov 2022 18:26:03 +0100, Pierre-Louis Bossart wrote:
> > As Kai mentioned it, this step helped with a S5 issue earlier in 2022.
> > Removing this will mechanically bring the issue back and break other
> > Chromebooks.
> 
> Yeah I don't mean that this fix is right, either.  But the earlier fix
> has apparently a problem and needs another fix.
> 
> Though, it's not clear why the full unregister of clients is needed at
> the first place; judging only from the patch description of commit
> 83bfc7e793b5, what we want is only to shut up the further user space
> action?  If so, just call snd_card_disconnect() would suffice?

I think the snd_card_disconnect() is what we are looking after here, but 
it's just easiest to do via unregister in SOF as that will trigger will 
look up the platform device, unregister it, and it eventually the driver 
owning the card will do the disconnect. Possibility for sure to do a more
direct implementation and not run the full unregister.

On the other end of the solution spectrum, we had this alternative to let 
user-space stay connected and just have the DSP implementations handle 
any pending work in their respective shutdown handlers. I.e. we had
"ASoC: SOF: Intel: pci-tgl: unblock S5 entry if DMA stop has failed"
https://github.com/thesofproject/linux/pull/3388

This was eventually dropped (and never sent upstream) as 83bfc7e793b5 got 
the same result, and covered all SOF platforms with a single code path.
Bringing this back is of course one option, but then this might suprise 
other platforms (which might have got used to user-space getting 
disconnected at shutdown via 83bfc7e793b5).

Br, Kai


More information about the Alsa-devel mailing list