All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Thomas Renninger <trenn@suse.de>
Cc: davej@redhat.com, sfr@canb.auug.org.au,
	linux-next@vger.kernel.org, cpufreq@vger.kernel.org
Subject: Re: [PATCH 1/2] CPUFREQ: powernow-k8: Forgot to use printk instead of WARN_ONCE in last patch
Date: Thu, 5 Feb 2009 13:42:34 +0100	[thread overview]
Message-ID: <20090205124234.GD8799@elte.hu> (raw)
In-Reply-To: <200902051327.16852.trenn@suse.de>


* Thomas Renninger <trenn@suse.de> wrote:

> Looking at WARN() again:
> #ifndef __WARN
> #ifndef __ASSEMBLY__
> extern void warn_slowpath(const char *file, const int line,
>                 const char *fmt, ...) __attribute__((format(printf, 3, 4)));
> #define WANT_WARN_ON_SLOWPATH
> #endif
> #define __WARN()                warn_slowpath(__FILE__, __LINE__, NULL)
> #define __WARN_printf(arg...)   warn_slowpath(__FILE__, __LINE__, arg)
> #else
> #define __WARN_printf(arg...)   do { printk(arg); __WARN(); } while (0)
> #endif
> 
> WARN_ONCE does throw a backtrace (warn_slowpath does) or I missed
> something...
> Thus WARN_ONCE makes a big difference to printk_once() (which does not
> exist? but would be neat...) and prints out the backtrace, right?

yes, correct. We use WARN()/WARN_ONCE() in places where an error is 
surprising and where we want to print a backtrace too.

In this case you are right to point out that it's not a kernel bug but a 
BIOS environment bug, and that the text itself uniquely identifies the place 
it comes from. So using a printk is perfectly fine.

There's a few cleanups necessary with the printk solution too though, see my 
previous mail for the details.

printk_once() would be nice indeed - it's a frequent construct.

	Ingo

  reply	other threads:[~2009-02-05 12:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-05 10:18 On top fixes for my last patches Thomas Renninger
2009-02-05 10:18 ` [PATCH 1/2] CPUFREQ: powernow-k8: Forgot to use printk instead of WARN_ONCE in last patch Thomas Renninger
2009-02-05 12:02   ` Ingo Molnar
2009-02-05 12:09     ` Thomas Renninger
2009-02-05 12:33       ` Ingo Molnar
2009-02-05 12:53         ` Thomas Renninger
2009-02-05 13:26           ` Ingo Molnar
2009-02-05 12:27     ` Thomas Renninger
2009-02-05 12:42       ` Ingo Molnar [this message]
2009-02-05 13:04         ` [tip:core/printk] printk: introduce printk_once() Ingo Molnar
2009-02-05 14:12           ` Thomas Renninger
2009-02-05 10:18 ` [PATCH 2/2] CPUFREQ: Use static or it won't compile if conservative and ondemand are set =y Thomas Renninger

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=20090205124234.GD8799@elte.hu \
    --to=mingo@elte.hu \
    --cc=cpufreq@vger.kernel.org \
    --cc=davej@redhat.com \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=trenn@suse.de \
    /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.