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