From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262676AbUKRIvW (ORCPT ); Thu, 18 Nov 2004 03:51:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262683AbUKRIvW (ORCPT ); Thu, 18 Nov 2004 03:51:22 -0500 Received: from mx2.elte.hu ([157.181.151.9]:46724 "EHLO mx2.elte.hu") by vger.kernel.org with ESMTP id S262676AbUKRIvU (ORCPT ); Thu, 18 Nov 2004 03:51:20 -0500 Date: Thu, 18 Nov 2004 10:52:53 +0100 From: Ingo Molnar To: Andrew Morton Cc: cliff white , linux-kernel@vger.kernel.org Subject: Re: 2.6.10-rc1-mm5 - badness in enable_irg, BUG Message-ID: <20041118095253.GA16054@elte.hu> References: <20041115093759.721ac964.cliffw@osdl.org> <20041117210219.43a36302.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041117210219.43a36302.akpm@osdl.org> User-Agent: Mutt/1.4.1i X-ELTE-SpamVersion: MailScanner 4.31.6-itk1 (ELTE 1.2) SpamAssassin 2.63 ClamAV 0.73 X-ELTE-VirusStatus: clean X-ELTE-SpamCheck: no X-ELTE-SpamCheck-Details: score=-4.9, required 5.9, autolearn=not spam, BAYES_00 -4.90 X-ELTE-SpamLevel: X-ELTE-SpamScore: -4 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org * Andrew Morton wrote: > > BUG: using smp_processor_id() in preemptible [00000001] code: mkdir/11768 > > caller is munmap_notify+0x7b/0x90 [oprofile] > > [] smp_processor_id+0xb5/0xc0 > > [] munmap_notify+0x7b/0x90 [oprofile] > > [] munmap_notify+0x7b/0x90 [oprofile] > > [] notifier_call_chain+0x2d/0x50 > > [] profile_munmap+0x33/0x50 > > [] sys_munmap+0x27/0x80 > > [] 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