All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Dave Jones <davej@redhat.com>, Adrian Bunk <bunk@kernel.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Andi Kleen <ak@muc.de>
Subject: Re: Print taint info in more places.
Date: Thu, 13 Dec 2007 23:25:06 -0800	[thread overview]
Message-ID: <47622FD2.2030607@goop.org> (raw)
In-Reply-To: <20071214013041.GH22304@redhat.com>

Dave Jones wrote:
> On Fri, Dec 14, 2007 at 01:03:50AM +0100, Adrian Bunk wrote:
>
>  > >  #ifndef HAVE_ARCH_BUG
>  > >  #define BUG() do { \
>  > > -	printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __FUNCTION__); \
>  > > +	printk(KERN_ERR "BUG: failure at %s:%d/%s()! (%s)\n",
>  > > +		__FILE__, __LINE__, __FUNCTION__, print_tainted()); \
>  > >  	panic("BUG!"); \
>  > >  } while (0)
>  > >  #endif
>  > >...
>  > 
>  > Note that this only changes a handful of architectures and most likely 
>  > not the ones you are interested in.
>
> Hmm, it appears that I was mistaken, and we never did patch x86.
> Which leaves me wondering if its worth it or not to  patch BUG()
> Anyways, here's the latest rev with the out-of-line changes as
> suggested by Andi.
>
> init/main.c may not be the best place for the ool variant. suggestions?
>   

lib/bug.c would be the place for architectures using
CONFIG_GENERIC_BUG.  x86 could be converted to use the BUG-trapping
mechanism for WARN_ON like Power does, so it would be inherently out of
line anyway.

    J

  reply	other threads:[~2007-12-14  7:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-13 22:49 Print taint info in more places Dave Jones
2007-12-13 23:08 ` Andi Kleen
2007-12-13 23:43   ` Mauricio Mauad Menegaz Filho
2007-12-13 23:52   ` Dave Jones
2007-12-14  0:12     ` Dave Jones
2007-12-14  0:03 ` Adrian Bunk
2007-12-14  0:16   ` Dave Jones
2007-12-14  1:30   ` Dave Jones
2007-12-14  7:25     ` Jeremy Fitzhardinge [this message]
2007-12-14  7:55       ` Dave Jones
2007-12-14 15:38     ` Matt Mackall
2007-12-14 16:56       ` Dave Jones
2007-12-14 12:09 ` Jon Masters

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=47622FD2.2030607@goop.org \
    --to=jeremy@goop.org \
    --cc=ak@muc.de \
    --cc=bunk@kernel.org \
    --cc=davej@redhat.com \
    --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.