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(). Then it's easier to cause a race. Takashi
