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 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.




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