Re: [PATCH 3/3] kernel/workqueue: Suppress a false positive lockdep complaint

[Bart Van Assche <bvanassche@acm.org>]

On Thu, 2018-10-25 at 17:34 +0200, Johannes Berg wrote:
> On Thu, 2018-10-25 at 15:05 +0000, Bart Van Assche wrote:
> 
> > @@ -2889,7 +2893,7 @@ static bool start_flush_work(struct work_struct *work, struct wq_barrier *barr,
> >  	 * workqueues the deadlock happens when the rescuer stalls, blocking
> >  	 * forward progress.
> >  	 */
> > -	if (!from_cancel &&
> > +	if (!from_cancel && (pwq->wq->flags & __WQ_HAS_BEEN_USED) &&
> >  	    (pwq->wq->saved_max_active == 1 || pwq->wq->rescuer)) {
> >  		lock_acquire_exclusive(&pwq->wq->lockdep_map, 0, 0, NULL,
> >  				       _THIS_IP_);
> 
> This also doesn't seem right to me. You shouldn't really care whether or
> not the workqueue has been used at this point, lockdep also doesn't do
> this for locks.
> 
> Any dependency you cause at some point can - at a future time - be taken
> into account when checking dependency cycles. Removing one arbitrarily
> just because you haven't actually executed anything *yet* just removes
> knowledge from lockdep. In the general case, this isn't right. Just
> because you haven't executd anything here doesn't mean that it's
> *impossible* to have executed something, right?

Please have a look at the call trace in the description of this patch and also
at the direct I/O code. The lockdep complaint in the description of this patch
really is a false positive. What I think needs further discussion is on how to
address this false positive - track whether or not a work queue has been used
or follow Tejun's proposal that I became aware of after I posted this patch,
namely introduce a new function for destroying a work queue that skips draining,
e.g. destroy_workqueue_skip_drain() (https://lkml.org/lkml/2018/10/24/2).

Thanks,

Bart.