Messages in this thread | | | Date | Thu, 18 Nov 2004 10:52:53 +0100 | From | Ingo Molnar <> | Subject | Re: 2.6.10-rc1-mm5 - badness in enable_irg, BUG |
| |
* 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.
> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |