lkml.org 
[lkml]   [2011]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH UPDATED] workqueue: relax lockdep annotation on flush_work()
From
Date
On Mon, 2011-01-03 at 16:00 +0100, Tejun Heo wrote:
> 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.

Ah, ok. I read it like: if the current thread is a rescue thread.




\
 
 \ /
  Last update: 2011-01-03 16:17    [from the cache]
©2003-2011 Jasper Spaans