From: Paul Mundt <lethal@linux-sh.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: hskinnemoen@atmel.com, nurhussein@gmail.com,
linux-kernel@vger.kernel.org, randy.dunlap@oracle.com,
arjan@infradead.org, mingo@elte.hu, a.p.zijlstra@chello.nl,
kyle@parisc-linux.org, schwidefsky@de.ibm.com
Subject: Re: Taint kernel after WARN_ON(condition) v2
Date: Fri, 16 May 2008 13:51:12 +0900 [thread overview]
Message-ID: <20080516045112.GA15431@linux-sh.org> (raw)
In-Reply-To: <20080515165134.cb7df5ed.akpm@linux-foundation.org>
On Thu, May 15, 2008 at 04:51:34PM -0700, Andrew Morton wrote:
> On Thu, 15 May 2008 13:06:35 +0900
> Paul Mundt <lethal@linux-sh.org> wrote:
>
> > On Wed, Feb 13, 2008 at 03:55:20PM +0100, Haavard Skinnemoen wrote:
> > > On Wed, 13 Feb 2008 22:27:40 +0800
> > > Nur Hussein <nurhussein@gmail.com> wrote:
> > >
> > > > This does not work on architectures where WARN_ON has its own definition.
> > > > These archs are:
> > > > 1. s390
> > > > 2. superh
> > > > 3. avr32
> > > > 4. parisc
> > >
> > > Hmm. Relying on the generic code in lib/bug.c qualifies as "own
> > > definition" these days? I think the patch below should take care of all
> > > four...unless I've misunderstood something.
> > >
> > > Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
> > >
> > > diff --git a/lib/bug.c b/lib/bug.c
> > > index 530f38f..0d67419 100644
> > > --- a/lib/bug.c
> > > +++ b/lib/bug.c
> > > @@ -35,6 +35,7 @@
> > >
> > > Jeremy Fitzhardinge <jeremy@goop.org> 2006
> > > */
> > > +#include <linux/kernel.h>
> > > #include <linux/list.h>
> > > #include <linux/module.h>
> > > #include <linux/bug.h>
> > > @@ -149,6 +150,7 @@ enum bug_trap_type report_bug(unsigned long bugaddr, struct pt_regs *regs)
> > > (void *)bugaddr);
> > >
> > > show_regs(regs);
> > > + add_taint(TAINT_WARN);
> > > return BUG_TRAP_TYPE_WARN;
> > > }
> > >
> >
> > I was just about to submit the exact same patch, so it looks like this
> > slipped through the cracks. Andrew, please apply.
>
> <goes dumpster-diving through lkml history>
>
> > Acked-by: Paul Mundt <lethal@linux-sh.org>
>
> I'd have ducked that one partly because of lack of changelog but mainly
> because it didn't look like anyone tested it.
>
> It's hard to see how it could go wrong, but stranger things have
> happened. To me. Regularly :(
>
It will work on any platform that implements warning traps through the
report_bug() path (ie, both report_bug() calling and BUG_TRAP_TYPE_WARN
checking), which is all of the platforms listed by Nur in his initial
comment as well as powerpc. And it's at least been verified on avr32 and
sh.
Either Havaard or I can resubmit this with a proper changelog if that
will help move things along, obviously it's not a very pressing patch one
way or the other, but consistency is good, and we're all likely to forget
about this again otherwise.
prev parent reply other threads:[~2008-05-16 4:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-13 14:27 Taint kernel after WARN_ON(condition) v2 Nur Hussein
2008-02-13 14:55 ` Haavard Skinnemoen
2008-05-15 4:06 ` Paul Mundt
2008-05-15 23:51 ` Andrew Morton
2008-05-16 4:51 ` Paul Mundt [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=20080516045112.GA15431@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=hskinnemoen@atmel.com \
--cc=kyle@parisc-linux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nurhussein@gmail.com \
--cc=randy.dunlap@oracle.com \
--cc=schwidefsky@de.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox