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

[Andrew Morton]

Ingo Molnar <mingo@xxxxxxx> wrote:
>
> 
> * 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.

OK.

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

Well can we at least stick a comment in there explaining to the
long-suffering reader what the difference is between smp_processor_id(),
_smp_processor_id() and __smp_processor_id()?  And what the architecture's
options are?

Or should we go through every arch and rename their smp_processor_id() to
__smp_processor_id()?  That would make sense, and would simplify that piece
of code.
-
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/