Messages in this thread | | | Date | Thu, 18 Nov 2004 01:15:04 -0800 | From | Andrew Morton <> | Subject | Re: 2.6.10-rc1-mm5 - badness in enable_irg, BUG |
| |
Ingo Molnar <mingo@elte.hu> wrote: > > > * Andrew Morton <akpm@osdl.org> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |