Re: 2.6.10-rc1-mm5 - badness in enable_irg, BUG

[Ingo Molnar]

* Andrew Morton <akpm@xxxxxxxx> wrote:

> > BUG: using smp_processor_id() in preemptible [00000001] code: mkdir/11768
> > caller is munmap_notify+0x7b/0x90 [oprofile]
> >  [<c020a465>] smp_processor_id+0xb5/0xc0
> >  [<f8912a4b>] munmap_notify+0x7b/0x90 [oprofile]
> >  [<f8912a4b>] munmap_notify+0x7b/0x90 [oprofile]
> >  [<c012b55d>] notifier_call_chain+0x2d/0x50
> >  [<c011dd93>] profile_munmap+0x33/0x50
> >  [<c01536f7>] sys_munmap+0x27/0x80
> >  [<c01046d3>] syscall_call+0x7/0xb
> 
> ho hum, I guess we should suppress these oprofile warnings somehow.
> 
> Ingo, is there an smp_processor_id() variant which bypasses the warning?

yeah, just use _smp_processor_id() for the checking-less variant.

> btw, this:

> is insane.   Any chance of simplifying it all?

since usually there are lots of arch-level false positives it didnt seem
prudent to enable the warning unconditionally for every arch. So an arch
can enable it right now by changing its smp_processor_id definition to
__smp_processor_id - and the #ifdefs will do their job to adapt. Once
most architectures have this enabled (right now only x86 and x64 have
it) we could simplify it down by making it unconditional but right now i
dont think it's a good idea.

	Ingo
-
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/