On 2022/02/12 3:59, Bart Van Assche wrote:
> On 2/10/22 11:27, syzbot wrote:
>> ======================================================
>> WARNING: possible circular locking dependency detected
>> 5.17.0-rc2-syzkaller-00398-gd8ad2ce873ab #0 Not tainted
>> ------------------------------------------------------
>
> Since the SRP initiator driver is involved, I will take a look.
> However, I'm not sure yet when I will have the time to post a fix.
>
> Thanks,
>
> Bart.
>
This problem was already handled by commit bf23747ee0532090 ("loop:
revert "make autoclear operation asynchronous"").
But this report might be suggesting us that we should consider
deprecating (and eventually getting rid of) system-wide workqueues
(declared in include/linux/workqueue.h), for since flush_workqueue()
synchronously waits for completion, sharing system-wide workqueues
among multiple modules can generate unexpected locking dependency
chain (like this report).
If some module needs flush_workqueue() or flush_*_work(), shouldn't
such module create and use their own workqueues?
Tejun, what do you think?
On 2/11/22 21:31, Tetsuo Handa wrote:
> But this report might be suggesting us that we should consider
> deprecating (and eventually getting rid of) system-wide workqueues
> (declared in include/linux/workqueue.h), for since flush_workqueue()
> synchronously waits for completion, sharing system-wide workqueues
> among multiple modules can generate unexpected locking dependency
> chain (like this report).
I do not agree with deprecating system-wide workqueues. I think that all
flush_workqueue(system_long_wq) calls should be reviewed since these are
deadlock-prone.
Thanks,
Bart.