lkml.org 
[lkml]   [2011]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH UPDATED] workqueue: relax lockdep annotation on flush_work()
Hello,

On Mon, Jan 03, 2011 at 03:54:50PM +0100, Peter Zijlstra wrote:
> On Mon, 2011-01-03 at 15:17 +0100, Tejun Heo wrote:
>
> > @@ -2384,8 +2384,18 @@ static bool start_flush_work(struct work_struct *work, struct wq_barrier *barr,
> > insert_wq_barrier(cwq, barr, work, worker);
> > spin_unlock_irq(&gcwq->lock);
> >
> > - lock_map_acquire(&cwq->wq->lockdep_map);
> > + /*
> > + * If @max_active is 1 or rescuer is in use, flushing another work
> > + * item on the same workqueue may lead to deadlock. Make sure the
> > + * flusher is not running on the same workqueue by verifying write
> > + * access.
> > + */
> > + if (cwq->wq->saved_max_active == 1 || cwq->wq->flags & WQ_RESCUER)
> > + lock_map_acquire(&cwq->wq->lockdep_map);
> > + else
> > + lock_map_acquire_read(&cwq->wq->lockdep_map);
> > lock_map_release(&cwq->wq->lockdep_map);
> > +
> > return true;
> > already_gone:
> > spin_unlock_irq(&gcwq->lock);
>
> Ah, but this violates the rule that you must always use the most strict
> constraints. Code doesn't know if it will run in a rescue thread or not,
> hence it must assume it does.

Hmmm? The code applies the most strict contraints. If the workqueue
has a rescuer, flushing another work from the workqueue will always
trigger lockdep warning. The rule is relaxed only for workqueues
which aren't used for memory reclaiming && support parallel execution.

Thanks.

--
tejun


\
 
 \ /
  Last update: 2011-01-03 16:03    [W:0.095 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site