staging: r8188eu: make _rtw_init_queue a macro
While testing latest updates I hit lockdep warning: [ 42.694425] ============================================ [ 42.694785] WARNING: possible recursive locking detected [ 42.695120] 5.14.0+ #25 Tainted: G C [ 42.695422] -------------------------------------------- [ 42.695747] RTW_CMD_THREAD/317 is trying to acquire lock: [ 42.696078] ffffc900006c90b0 (&pqueue->lock){+.-.}-{3:3}, at: _rtw_alloc_network+0x1e/0x321 [r8188eu] [ 42.696686] [ 42.696686] but task is already holding lock: [ 42.697148] ffffc900006c9100 (&pqueue->lock){+.-.}-{3:3}, at: rtw_update_scanned_network+0x31/0x76b [r8188eu] [ 42.697758] [ 42.697758] other info that might help us debug this: [ 42.698326] Possible unsafe locking scenario: [ 42.698326] [ 42.698696] CPU0 [ 42.698847] ---- [ 42.698997] lock(&pqueue->lock); [ 42.699209] lock(&pqueue->lock); [ 42.699418] [ 42.699418] *** DEADLOCK *** [ 42.699418] [ 42.699768] May be due to missing lock nesting notation It's false positive, since all queue spinlocks are initialized via private API which has pqueue as agrument. Fix it by making _rtw_init_queue a macro instead of function + removed unneeded _ prefix. Signed-off-by:Pavel Skripkin <paskripkin@gmail.com> Link: https://lore.kernel.org/r/20210908194309.9086-1-paskripkin@gmail.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Showing
Please register or sign in to comment