New lockdep warning in broonie/sound.git/for-5.17

Hans de Goede hdegoede at redhat.com
Mon Jan 10 12:49:00 CET 2022


Hi All,

After rebasing my recent Bay Trail rt5640 patch series on top of
broonie/sound.git/for-5.17 I'm seeing the following new lockdep
warning on devices running the rebased branch:

[  131.404755] ============================================
[  131.404762] WARNING: possible recursive locking detected
[  131.404769] 5.16.0-rc8+ #758 Tainted: G         C       
[  131.404777] --------------------------------------------
[  131.404782] pipewire/1372 is trying to acquire lock:
[  131.404789] ffffa090838535a0 (&group->mutex){+.+.}-{3:3}, at: _snd_pcm_stream_lock_irqsave+0x2b/0x30 [snd_pcm]
[  131.404845] 
               but task is already holding lock:
[  131.404851] ffffa09088e981a0 (&group->mutex){+.+.}-{3:3}, at: snd_pcm_action_lock_irq+0x2d/0x90 [snd_pcm]
[  131.404894] 
               other info that might help us debug this:
[  131.404899]  Possible unsafe locking scenario:

[  131.404905]        CPU0
[  131.404909]        ----
[  131.404913]   lock(&group->mutex);
[  131.404923]   lock(&group->mutex);
[  131.404932] 
                *** DEADLOCK ***

[  131.404937]  May be due to missing lock nesting notation

[  131.404942] 1 lock held by pipewire/1372:
[  131.404950]  #0: ffffa09088e981a0 (&group->mutex){+.+.}-{3:3}, at: snd_pcm_action_lock_irq+0x2d/0x90 [snd_pcm]
[  131.404994] 
               stack backtrace:
[  131.405001] CPU: 2 PID: 1372 Comm: pipewire Tainted: G         C        5.16.0-rc8+ #758
[  131.405012] Hardware name: ASUSTeK COMPUTER INC. TF103CE/TF103CE, BIOS 5.6.5 09/03/2015
[  131.405019] Call Trace:
[  131.405022] sd 0:0:0:0: [sda] 31805439 512-byte logical blocks: (16.3 GB/15.2 GiB)
[  131.405027]  <TASK>
[  131.405034]  dump_stack_lvl+0x59/0x73
[  131.405057]  __lock_acquire.cold+0xc5/0x2b8
[  131.405081]  lock_acquire+0xb5/0x2b0
[  131.405095]  ? _snd_pcm_stream_lock_irqsave+0x2b/0x30 [snd_pcm]
[  131.405128]  ? lock_is_held_type+0xa8/0x120
[  131.405148]  __mutex_lock+0x92/0x8a0
[  131.405163]  ? _snd_pcm_stream_lock_irqsave+0x2b/0x30 [snd_pcm]
[  131.405195]  ? mark_held_locks+0x49/0x70
[  131.405208]  ? _snd_pcm_stream_lock_irqsave+0x2b/0x30 [snd_pcm]
[  131.405241]  ? _raw_spin_unlock_irqrestore+0x2d/0x50
[  131.405260]  ? _snd_pcm_stream_lock_irqsave+0x2b/0x30 [snd_pcm]
[  131.405291]  _snd_pcm_stream_lock_irqsave+0x2b/0x30 [snd_pcm]
[  131.405322]  dpcm_be_dai_trigger+0xae/0x410 [snd_soc_core]
[  131.405404] sda: detected capacity change from 0 to 31805439
[  131.405406]  dpcm_fe_dai_do_trigger+0x84/0x1b0 [snd_soc_core]
[  131.405480]  snd_pcm_action+0x79/0xc0 [snd_pcm]
[  131.405515]  snd_pcm_action_lock_irq+0x3b/0x90 [snd_pcm]
[  131.405549]  snd_pcm_ioctl+0x23/0x30 [snd_pcm]
[  131.405581]  __x64_sys_ioctl+0x82/0xb0
[  131.405599]  do_syscall_64+0x3b/0x90
[  131.405612]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  131.405624] RIP: 0033:0x7f70c0b2e37b
[  131.405637] Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 2a 0f 00 f7 d8 64 89 01 48
[  131.405647] RSP: 002b:00007ffdfdd46e88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[  131.405660] RAX: ffffffffffffffda RBX: 00005584f8f43a40 RCX: 00007f70c0b2e37b
[  131.405669] RDX: 0000000000000000 RSI: 0000000000004142 RDI: 0000000000000048
[  131.405676] RBP: 0000000000000002 R08: 00007f70b16eb000 R09: 0000000000000800
[  131.405684] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[  131.405692] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000003
[  131.405711]  </TASK>

It seems we now have some nested locking going on without proper lockdep
annotations (that or a deadlock, but everything still seems to work fine).

Regards,

Hans



More information about the Alsa-devel mailing list