All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@osdl.org>
Cc: cliffw@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: 2.6.10-rc1-mm5 - badness in enable_irg, BUG
Date: Thu, 18 Nov 2004 11:27:09 +0100	[thread overview]
Message-ID: <20041118102709.GA20901@elte.hu> (raw)
In-Reply-To: <20041118011504.7dc87fe6.akpm@osdl.org>


* Andrew Morton <akpm@osdl.org> wrote:

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

doc-patch against -rc2-mm1 attached.

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

initially the rate of false positives is like 90%, so there would only
be annoyance coming out of this patch. Arch maintainers should have the
ability to enable this on their own pace i think. Once the majority of 
arches have enabled this we can force it on for all architectures.

	Ingo

Signed-off-by: Ingo Molnar <mingo@elte.hu>

--- linux/include/linux/smp.h.orig
+++ linux/include/linux/smp.h
@@ -109,12 +109,24 @@ static inline void smp_send_reschedule(i
 
 #endif /* !SMP */
 
+/*
+ * DEBUG_PREEMPT support: check whether smp_processor_id() is being
+ * used in a preemption-safe way.
+ *
+ * An architecture has to enable this debugging code explicitly.
+ * It can do so by renaming the smp_processor_id() macro to
+ * __smp_processor_id().  This should only be done after some minimal
+ * testingy, because usually there are a number of false positives
+ * that an architecture will trigger.
+ *
+ * To fix a false positives (i.e. smp_processor_id() use that the
+ * debugging code reports but which use for some reason is legal),
+ * change the smp_processor_id() reference to _smp_processor_id(),
+ * which is the nondebug variant.  NOTE: dont use this to hack around
+ * real bugs.
+ */
 #ifdef __smp_processor_id
 # if defined(CONFIG_PREEMPT) && defined(CONFIG_DEBUG_PREEMPT)
-  /*
-   * temporary debugging check detecting places that use
-   * smp_processor_id() in a potentially unsafe way:
-   */
    extern unsigned int smp_processor_id(void);
 # else
 #  define smp_processor_id() __smp_processor_id()

      reply	other threads:[~2004-11-18  9:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-15 17:37 2.6.10-rc1-mm5 - badness in enable_irg, BUG cliff white
2004-11-15 17:49 ` cliff white
2004-11-18  5:02 ` Andrew Morton
2004-11-18  9:52   ` Ingo Molnar
2004-11-18  9:15     ` Andrew Morton
2004-11-18 10:27       ` Ingo Molnar [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041118102709.GA20901@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@osdl.org \
    --cc=cliffw@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.