On Thu, Aug 17, 2017 at 09:48:11AM +0200, Ingo Molnar wrote: > > * 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. > I have been trying to reproduce the false positive on my machine, but haven't succeeded. ;-( Have you tried this? But I have been using this patch for a day and haven't shoot my foot yet. > BTW., I don't think the #ifdef is necessary: lockdep_init_map_crosslock should map > to nothing when lockdep is disabled, right? IIUC, lockdep_init_map_crosslock is only defined when CONFIG_LOCKDEP_CROSSRELEASE=y, moreover, completion::map, which used as the parameter of lockdep_init_map_crosslock(), is only defined when CONFIG_LOCKDEP_COMPLETE=y. So the #ifdef is necessary, but maybe we can clean this thing up in the future. I will send a proper patch, so the thing could move forwards. Just a minute ;-) Regards, Boqun > > Thanks, > > Ingo
Attachment:
signature.asc
Description: PGP signature