On Wed, 08 Nov 2023 13:39:22 +0100, Takashi Iwai wrote: > > On Wed, 08 Nov 2023 13:14:15 +0100, > 강신형 wrote: > > > > > Thanks for the patch. But this change may break the current working > > > behavior; e.g. when two proc reads are running concurrently, one would > > > be aborted unexpectedly. > > > > > > IIUC, the problem is the call of proc_remove(), and this call itself > > > can be outside the global mutex. > > > > > > Could you check whether the patch below works instead? (Note that > > > it's only compile-tested.) It makes the proc_remove() called at > > > first, then clearing the internal entries. The function was renamed > > > accordingly for avoiding confusion, too. > > > > > > > > > Takashi > > > > You are right. My patch is just for avoiding the deadlock. > > It may lead to other problem instead the deadlock(e.g. USB sound card > > registration failure) > > Your patch works well without any problems. > > But I can't confirm that the problem is solved or not. > > because the issue has occurred only once until now. > > (Test method: USB insertion / removal during a call) > > Maybe you can reproduce it more easily by adding some delay > (e.g. ssleep(2)) before mutex_lock() in snd_info_entry_open(). ... in our case, it's rather snd_info_text_entry_open(). > Then it's easier to cause a race. I could actually reproduce the bug with the extra delay, and confirmed that my patch works around it. I'm going to submit a proper patch. Takashi
