On Fri, Sep 03, 2021 at 10:33:56PM +0300, Pavel Skripkin wrote: > 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@xxxxxxxxx> > Fixes: 15865124feed ("staging: r8188eu: introduce new core dir for RTL8188eu driver") No need for "Fixes:" on this, as it's not a bug, it's just a badly designed implementation. thanks, greg k-h