public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: "Shargorodsky Atal (EXT-Teleca/Helsinki)" 
	<ext-atal.shargorodsky@nokia.com>
Cc: Simon Kagstrom <simon.kagstrom@netinsight.net>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	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: Sat, 24 Oct 2009 20:05:57 +0300	[thread overview]
Message-ID: <1256403957.29885.357.camel@localhost> (raw)
In-Reply-To: <1256313202.5824.60.camel@atal-desktop>

On Fri, 2009-10-23 at 18:53 +0300, Shargorodsky Atal
(EXT-Teleca/Helsinki) wrote:
> Hi all,
> 
> On Thu, 2009-10-22 at 08:25 +0200, ext Simon Kagstrom wrote:
> 
> > Thanks to everyone for the reviewing and suggestions!
> > 
> 
> I have a couple of questions:
> 
> 1. If somebody writes a module that uses dumper for uploading the
> oopses/panics logs via some pay-per-byte medium,  since he has no way
> to know in a module if the panic_on_oops flag is set, he'll have
> to upload both oops and the following panic, because he does not
> know for sure that the panic was caused by the oops. Hence he
> pays twice for the same information, right?

Looks like a valid point to me. Indeed, in this case we will first call
'kmsg_dump(KMSG_DUMP_OOPS)' from 'oops_exit()', and then call it from
'panic()'. And the dumper may dump the same information, which is not
nice.

I've looked briefly and tried to figure out how to fix this. But I
cannot find an clean way. And I was confused by the die/oops/etc code.
My question is, why the code does not work the following way instead?

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 2d8a371..8f322c7 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -235,13 +235,12 @@ void __kprobes oops_end(unsigned long flags, struct pt_regs *regs, int signr)
        raw_local_irq_restore(flags);
        oops_exit();

-       if (!signr)
-               return;
        if (in_interrupt())
                panic("Fatal exception in interrupt");
        if (panic_on_oops)
                panic("Fatal exception");
-       do_exit(signr);
+       if (signr)
+               do_exit(signr);
 }

 int __kprobes __die(const char *str, struct pt_regs *regs, long err)

If the code worked like this, I think the problem indicated by Atal
could be easily fixed.

> 2. We tried to use panic notifiers mechanism to print additional
> information that we want to see in mtdoops logs and it worked well,
> but having the kmsg_dump(KMSG_DUMP_PANIC) before the
> atomic_notifier_call_chain() breaks this functionality.
> Can we the call kmsg_dump() after the notifiers had been invoked?

Atal, I think you should just attach your patch, it is easier to express
what you mean.

But for me it looks like atomic_notifier_call_chain() can be moved up.

Anyway, please, show your patch.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)


  reply	other threads:[~2009-10-24 17:06 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]: core: Add kernel message dumper to call on oopses and panics 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 [this message]
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
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=1256403957.29885.357.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=aaro.koskinen@nokia.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --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=simon.kagstrom@netinsight.net \
    --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