Re: lockdep and kmemcheck

[Peter Zijlstra]

On Fri, 2012-06-08 at 15:10 +0900, Tejun Heo wrote:
> On Thu, Jun 07, 2012 at 09:45:16PM +0200, Borislav Petkov wrote:
> > static struct worker *create_worker(struct global_cwq *gcwq, bool bind)
> > {
> >         bool on_unbound_cpu = gcwq->cpu == WORK_CPU_UNBOUND;
> >         struct worker *worker = NULL;
> >         int id = -1;
> > 
> >         spin_lock_irq(&gcwq->lock);
> >         while (ida_get_new(&gcwq->worker_ida, &id)) {
> >                 spin_unlock_irq(&gcwq->lock);
> >                 if (!ida_pre_get(&gcwq->worker_ida, GFP_KERNEL))
> > 
> > and GFP_KERNEL has __GFP_FS.
> > 
> > > >  [<ffffffff81ae441d>] init_workqueues+0x1f2/0x393
> > > >  [<ffffffff81ae422b>] ? usermodehelper_init+0x36/0x36
> > > >  [<ffffffff81ae422b>] ? usermodehelper_init+0x36/0x36
> > > >  [<ffffffff81002122>] do_one_initcall+0x122/0x180
> > > >  [<ffffffff81acbc7a>] kernel_init+0x9b/0x1f6
> > > >  [<ffffffff815c1f74>] kernel_thread_helper+0x4/0x10
> > > >  [<ffffffff815c0274>] ? retint_restore_args+0x13/0x13
> > > >  [<ffffffff81acbbdf>] ? start_kernel+0x3d2/0x3d2
> > > >  [<ffffffff815c1f70>] ? gs_change+0x13/0x13
> > > > ---[ end trace 6d450e935ee1897c ]---
> > > > MCE: In-kernel MCE decoding enabled.
> > > > NMI watchdog: enabled, takes one hw-pmu counter.
> > 
> > Let's add some more people to CC.
> > 
> > Tejun, this create_worker() uses ida_pre_get() with GFP_KERNEL mask
> > but lockdep complains about __GFP_FS allocations with IRQs off in
> > __lockdep_trace_alloc. What's up?
> 
> The GFP_KERNEL allocation is right after spin_unlock_irq().  I suppose
> this is from early boot before IRQs are brought online, right?  My
> memory is very fuzzy now but ISTR irq debug code and lockdep having
> workarounds for early boot.  Peter?

early_boot_irqs_disabled, but kernel_init() is way past that, that's
where we've forked the first thread and are fully scheduling already.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/