Skip to content
Commit d1cfdcad authored by Fabio Aiuto's avatar Fabio Aiuto Committed by Greg Kroah-Hartman
Browse files

staging: rtl8723bs: unwrap initialization of queues



unwrap initialization of queues to avoid false positive
lockdep warning:

[   27.350258] ============================================
[   27.350267] WARNING: possible recursive locking detected
[   27.350276] 5.14.0-rc6+ #16 Tainted: G         C OE
[   27.350288] --------------------------------------------
[   27.350295] RTW_CMD_THREAD/679 is trying to acquire lock:
[   27.350306] ffffa846c03290c8 (&(pqueue->lock)){+.-.}-{2:2},
		at: rtw_alloc_network+0x1b/0xa0 [r8723bs]
[   27.350441]
               but task is already holding lock:
[   27.350448] ffffa846c0329118 (&(pqueue->lock)){+.-.}-{2:2},
		at: rtw_update_scanned_network+0x33/0x1d0 [r8723bs]
[   27.350573]
               other info that might help us debug this:
[   27.350581]  Possible unsafe locking scenario:

[   27.350588]        CPU0
[   27.350594]        ----
[   27.350600]   lock(&(pqueue->lock));
[   27.350614]   lock(&(pqueue->lock));
[   27.350627]
                *** DEADLOCK ***

[   27.350634]  May be due to missing lock nesting notation

[   27.350641] 2 locks held by RTW_CMD_THREAD/679:
[   27.350652]  #0: ffffa846c0329038 (&pmlmepriv->lock){+...}-{2:2},
	at: rtw_survey_event_callback+0x2d/0xe0 [r8723bs]
[   27.350780]  #1: ffffa846c0329118 (&(pqueue->lock)){+.-.}-{2:2},
	at: rtw_update_scanned_network+0x33/0x1d0 [r8723bs]
[   27.350907]
               stack backtrace:
[   27.350916] CPU: 3 PID: 679 Comm: RTW_CMD_THREAD Tainted: G
		C OE     5.14.0-rc6+ #16
[   27.350933] Hardware name: LENOVO 80NR/Madrid, BIOS DACN25WW
		08/20/2015
[   27.350943] Call Trace:
[   27.350959]  dump_stack_lvl+0x56/0x6f
[   27.350982]  __lock_acquire.cold.79+0x137/0x298
[   27.351012]  lock_acquire+0xb4/0x2c0
[   27.351031]  ? rtw_alloc_network+0x1b/0xa0 [r8723bs]
[   27.351140]  ? rtw_update_scanned_network+0x33/0x1d0 [r8723bs]
[   27.351254]  _raw_spin_lock_bh+0x34/0x40
[   27.351271]  ? rtw_alloc_network+0x1b/0xa0 [r8723bs]
[   27.351378]  rtw_alloc_network+0x1b/0xa0 [r8723bs]
[   27.351488]  rtw_update_scanned_network+0xa5/0x1d0 [r8723bs]
[   27.351605]  rtw_survey_event_callback+0x54/0xe0 [r8723bs]
[   27.351719]  mlme_evt_hdl+0x4e/0x70 [r8723bs]
[   27.351839]  rtw_cmd_thread+0x16c/0x3d0 [r8723bs]
[   27.351945]  ? rtw_stop_cmd_thread+0x50/0x50 [r8723bs]
[   27.352045]  kthread+0x136/0x160
[   27.352064]  ? set_kthread_struct+0x40/0x40
[   27.352083]  ret_from_fork+0x22/0x30

This happens because the wrapping function _rtw_init_queues()
bring lockdep considering all queues as a single one. But
all queues are different with their own lock.

Applied the following semantic patch:

@@
expression a;
@@

-       _rtw_init_queue(&a);
+       INIT_LIST_HEAD(&a.queue);
+       spin_lock_init(&a.lock);

Reported-by: default avatarHans De Goede <hdegoede@redhat.com>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
Signed-off-by: default avatarFabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/c2c3a18cc2b883feab74f150ccbaa4f2cc11995c.1630307025.git.fabioaiuto83@gmail.com


Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
parent 8ffd91d9
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment