staging: r8188eu: remove _rtw_mutex_{init,free}
While testing Fabio's patch I hit lockdep warning about possible deadlock: [ 252.063305] WARNING: possible recursive locking detected [ 252.063642] 5.14.0+ #9 Tainted: G C [ 252.063946] -------------------------------------------- [ 252.064282] ip/335 is trying to acquire lock: [ 252.064560] ffff888009ebad28 (pmutex){+.+.}-{4:4}, at: usbctrl_vendorreq+0xc5/0x4a0 [r8188eu] [ 252.065168] [ 252.065168] but task is already holding lock: [ 252.065536] ffffffffc021b3b8 (pmutex){+.+.}-{4:4}, at: netdev_open+0x3a/0x5f [r8188eu] [ 252.066085] [ 252.066085] other info that might help us debug this: [ 252.066494] Possible unsafe locking scenario: [ 252.066494] [ 252.066866] CPU0 [ 252.067025] ---- [ 252.067184] lock(pmutex); [ 252.067367] lock(pmutex); There is one problem with this warning: there is no pmutex in this driver, *BUT* all mutexes are initialized via private _rtw_mutex_init API, which had struct mutex *pmutex argument. So, all mutexes in this driver had same name in lockdep map. Of course, lockdep will complain about any nested locking. Fix it by open-coding _rtw_mutex_{init,free} wrappers, because we do not need them at all. Cc: Fabio M. De Francesco <fmdefrancesco@gmail.com> Signed-off-by:Pavel Skripkin <paskripkin@gmail.com> Link: https://lore.kernel.org/r/20210904124747.30050-1-paskripkin@gmail.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Showing
Please register or sign in to comment