* Boqun Feng <boqun.feng@xxxxxxxxx> wrote:
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -2431,6 +2431,27 @@ struct wq_barrier {
> struct task_struct *task; /* purely informational */
> };
>
> +#ifdef CONFIG_LOCKDEP_COMPLETE
> +# define INIT_WQ_BARRIER_ONSTACK(barr, func, target) \
> +do { \
> + INIT_WORK_ONSTACK(&(barr)->work, func); \
> + __set_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(&(barr)->work)); \
> + lockdep_init_map_crosslock((struct lockdep_map *)&(barr)->done.map, \
> + "(complete)" #barr, \
> + (target)->lockdep_map.key, 1); \
> + __init_completion(&barr->done); \
> + barr->task = current; \
> +} while (0)
> +#else
> +# define INIT_WQ_BARRIER_ONSTACK(barr, func, target) \
> +do { \
> + INIT_WORK_ONSTACK(&(barr)->work, func); \
> + __set_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(&(barr)->work)); \
> + init_completion(&barr->done); \
> + barr->task = current; \
> +} while (0)
> +#endif
Is there any progress with this bug? This false positive warning regression is
blocking the locking tree.
BTW., I don't think the #ifdef is necessary: lockdep_init_map_crosslock should map
to nothing when lockdep is disabled, right?
Thanks,
Ingo
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
