From: Simon Kagstrom <simon.kagstrom@netinsight.net>
To: "Shargorodsky Atal (EXT-Teleca/Helsinki)"
<ext-atal.shargorodsky@nokia.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>,
Artem Bityutskiy <dedekind1@gmail.com>,
linux-mtd <linux-mtd@lists.infradead.org>,
David Woodhouse <dwmw2@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
"Koskinen Aaro (Nokia-D/Helsinki)" <aaro.koskinen@nokia.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH v11 4/5] core: Add kernel message dumper to call on oopses and panics
Date: Mon, 26 Oct 2009 12:53:16 +0100 [thread overview]
Message-ID: <20091026125316.0283e322@marrow.netinsight.se> (raw)
In-Reply-To: <1256553393.5822.24.camel@atal-desktop>
On Mon, 26 Oct 2009 12:36:33 +0200
"Shargorodsky Atal (EXT-Teleca/Helsinki)" <ext-atal.shargorodsky@nokia.com> wrote:
> > > I can think of a couple of way to figure it out in the module
> > > itself, but I could not think of any clean way to do it.
> >
> > This is correct, and the mtdoops driver has some provisions to handle
> > this. First, there is a parameter to the module to specify whether
> > oopses should be dumped at all - I added this for the particular case
> > that someone has panic_on_oops set.
>
> It takes care of most of the situations, but panic_on_oops
> can be changed any time, even after the module is loaded.
Yes, but this parameter is settable at runtime as well by writing
to /sys/module/mtdoops/parameters/dump_oops.
> > Second, it does not dump oopses directly anyway, but puts it in a work
> > queue. That way, if panic_on_oops is set, it will store the panic but
> > the oops (called from the workqueue) will not get written anyway.
> >
>
> AFAIK, mtdoops does not put oopses in a work queue. And if by any chance
> it does, then I think it's wrong and might lead to missed oopses, as
> the oops might be because of the work queues themselves, or it might
> look to the kernel like some non-fatal fault, but actually it's a
> sign of a much more catastrophic failure - IOMMU device garbaging
> memory, for instance.
I was referring to my patches to it, sorry. It's in the patch "[PATCH v7 5/5]:
mtdoops: refactor as a kmsg_dumper" (as well as the parameter to dump
oopses at all).
There are other situations which will make dumping problematic as well,
e.g., crashes in the mtd code, so there are certainly some cases which
will be difficult to catch. But in the panic_on_oops case or
oops-in-interrupt, the oops won't be missed and won't be outputted
twice for mtdoops.
Anyway, I understand your problem and agree that it would be good to
fix. Moving up crash_kexec() and the notifiers will at least fix your
second issue. For the double-output-of-oopses, I don't see a good way
to fix it unless relying on the module to correct it like above.
// Simon
next prev parent reply other threads:[~2009-10-26 11:53 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20091015094057.7298e0d7@marrow.netinsight.se>
2009-10-15 7:48 ` [PATCH v7 4/5]: " Simon Kagstrom
2009-10-15 9:31 ` Ingo Molnar
2009-10-15 14:10 ` [PATCH v8 4/5] " Simon Kagstrom
2009-10-15 15:46 ` Ingo Molnar
2009-10-16 7:46 ` [PATCH v9 " Simon Kagstrom
2009-10-16 8:09 ` Ingo Molnar
2009-10-16 8:24 ` Artem Bityutskiy
2009-10-16 9:25 ` [PATCH v10 " Simon Kagstrom
2009-10-16 10:10 ` Ingo Molnar
2009-10-16 11:00 ` Artem Bityutskiy
2009-10-16 12:57 ` Ingo Molnar
2009-10-16 12:09 ` [PATCH v11 " Simon Kagstrom
2009-10-19 11:48 ` Artem Bityutskiy
2009-10-19 12:50 ` Ingo Molnar
2009-10-21 23:33 ` Linus Torvalds
2009-10-22 6:25 ` Simon Kagstrom
2009-10-22 6:36 ` Artem Bityutskiy
2009-10-23 7:22 ` Ingo Molnar
2009-10-23 15:53 ` Shargorodsky Atal (EXT-Teleca/Helsinki)
2009-10-24 17:05 ` Artem Bityutskiy
2009-10-26 10:40 ` Shargorodsky Atal (EXT-Teleca/Helsinki)
2009-10-26 7:41 ` Simon Kagstrom
2009-10-26 10:36 ` Shargorodsky Atal (EXT-Teleca/Helsinki)
2009-10-26 11:53 ` Simon Kagstrom [this message]
2009-10-26 15:13 ` Shargorodsky Atal (EXT-Teleca/Helsinki)
2009-10-26 15:37 ` Simon Kagstrom
2009-10-16 11:25 ` [PATCH v10 " Aaro Koskinen
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=20091026125316.0283e322@marrow.netinsight.se \
--to=simon.kagstrom@netinsight.net \
--cc=aaro.koskinen@nokia.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=ext-atal.shargorodsky@nokia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®