linux-kernel - Re: [PATCH] panic.c: export panic_on

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091012071239.608a74c9@infradead.org>
Date:	Mon, 12 Oct 2009 07:12:39 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Artem Bityutskiy <dedekind1@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Koskinen Aaro (Nokia-D/Helsinki)" <aaro.koskinen@...ia.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Simon Kagstrom <simon.kagstrom@...insight.net>,
	linux-mtd <linux-mtd@...ts.infradead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] panic.c: export panic_on_oops

On Mon, 12 Oct 2009 13:37:58 +0200
Ingo Molnar <mingo@...e.hu> wrote:

> 
> * Artem Bityutskiy <dedekind1@...il.com> wrote:
> 
> > On Mon, 2009-10-12 at 13:15 +0200, ext Ingo Molnar wrote:
> > > > We use the mtdoops module which stores oopses on the Flash
> > > > partition, in order to make it possible to analyze them later.
> > > > And mtdoops needs to know whether 'panic_on_oops' is on or off.
> > > > Thus, we need this variable to be exported.
> > > 
> > > hm, why does it need it? Could you send the patch please that
> > > makes use of it (as an easy way to explain the need for the
> > > export) - current upstream drivers/mtd/mtdoops.c doesnt need it
> > > so it must be some pending change.
> > 
> > Yes, current drivers/mtd/mtdoops.c does not need it, but we have
> > this patch:
> > 
> > http://lists.infradead.org/pipermail/linux-mtd/2009-October/027450.html
> > 
> > which makes sure mtdoops writes the oops log immediately, because we
> > have 'panic_on_oops' set so this is our last chance to save the
> > oops.
> > 
> > Here is the patch inlined as well:
> > 
> > Author: Aaro Koskinen <aaro.koskinen@...ia.com>
> > Date:   Thu Oct 1 18:16:55 2009 +0300
> > 
> >     mtd: mtdoops: do not schedule work if we are going to die
> > 
> >     If panic_on_oops is set, the log should be written right away
> >     because this is not going to be a second chance.
> > 
> >     Signed-off-by: Aaro Koskinen <aaro.koskinen@...ia.com>
> >     Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@...ia.com>
> > 
> > diff --git a/drivers/mtd/mtdoops.c b/drivers/mtd/mtdoops.c
> > index 1060337..ac67833 100644
> > --- a/drivers/mtd/mtdoops.c
> > +++ b/drivers/mtd/mtdoops.c
> > @@ -335,7 +335,7 @@ static void mtdoops_console_sync(void)
> >         cxt->ready = 0;
> >         spin_unlock_irqrestore(&cxt->writecount_lock, flags);
> > 
> > -       if (mtd->panic_write && in_interrupt())
> > +       if (mtd->panic_write && (in_interrupt() || panic_on_oops))
> >                 /* Interrupt context, we're going to panic so try
> > and log */ mtdoops_write(cxt, 1);
> 
> Hm, the code seems to be somewhat confused about this. It tries to
> guess when it's panic-ing, right? in_interrupt() is the wrong test
> for that.
> 
> mtdoops_console_sync() gets called by regular printk() as well via:
> 
> static void
> mtdoops_console_write(struct console *co, const char *s, unsigned int
> count) {
>         struct mtdoops_context *cxt = co->data;
>         struct mtd_info *mtd = cxt->mtd;
>         unsigned long flags;
> 
>         if (!oops_in_progress) {
>                 mtdoops_console_sync();
>                 return;
> 
> I think this is all layered incorrectly - because mtdoops (which is a 
> _VERY_ cool debugging facility btw - i wish generic x86 had something 
> like that) tries to be a 'driver' and tries to achieve these things 
> without modifying the core kernel.
> 
> But it really should do that. We can certainly enhance the core
> kernel logic to tell the console driver more clearly when printk
> should go out immediately.
> 
> Instead of using oops_in_progress it might be better to go into 'sync 
> immeditately' mode if the kernel gets tainted.

actually there are very nice "begin of oops" and "end of oops"
functions... they are the perfect places for this ;-)

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/