From: Joshua Wise <jwise@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Kyle McMartin <kyle@mcmartin.ca>,
linux-kernel@vger.kernel.org, thockin@google.com,
mikew@google.com, masouds@google.com
Subject: Re: [PATCH] [revised -- version 2] Info dump on Oops or panic()
Date: Thu, 28 Jun 2007 19:15:14 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0706281850490.617@internets.corp.google.com> (raw)
In-Reply-To: <20070628164855.012344cd.akpm@linux-foundation.org>
On Thu, 28 Jun 2007, Andrew Morton wrote:
> Your email client is doing space-stuffing. It's easy enough to fix at this
> end, but even easier if you fix it ;)
Aw darn :( Stupid PINE. I'll fix it for the next patch.
>> + atomic_notifier_call_chain(&info_dumper_list, 0, NULL);
[...]
> So... Please consider abandoning the notifier-chain and just go for a
> simple function call.
As we discovered some minutes ago, there appears to be infrastructure for this
already -- the die_chain. For thsoe of you who don't know, the die_chain
gets called from notify_die. It exists on almost all architectures. On i386,
it gets called from die() on arch/i386/kernel/traps.c:417 -- before
registers are scrolled by. So, if we want our own specific output there,
like utsname or uptime, then we can get it.
There exists a DIE_PANIC type on some architectures, but it's never actually
... used. So, I will probably write a patch to add it on all architectures,
and use it in the panic routines.
>> +ATOMIC_NOTIFIER_HEAD(info_dumper_list);
>> +EXPORT_SYMBOL(info_dumper_list);
>
> That export isn't needed.
If I want someone else to access it, like a module, it is... But, I guess
if I wanted to act as per canon, I should just do register functions, and
export those. On the die_chain, those are EXPORT_SYMBOL_GPL, FWIW
> Again, a deref of current->nsproxy->uts_ns->name at oops-time has risks.
>
> This string could be precalculated, no?
Yes, and will be.
> I don't know what to do here. It will be hard to find a read-the-time
> function which is a) lockless and b) available on all architectures and
> configs.
>
> If you can find a way to use plain old jiffies, that'd be good.
jiffies sounds good enough to me.
There seems to be some opposition to the utsname and uptime patches. I'll
take a look at those here and see what I can do to make those a little more
pleasing to non-Google users. Expect a patch for DIE_PANIC tomorrow...
joshua
next prev parent reply other threads:[~2007-06-29 2:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-28 22:05 [PATCH] " Joshua Wise
2007-06-28 22:18 ` Kyle McMartin
2007-06-28 23:12 ` [PATCH] [revised -- version 2] " Joshua Wise
2007-06-28 23:48 ` Andrew Morton
2007-06-29 2:15 ` Joshua Wise [this message]
2007-06-28 23:54 ` [PATCH] " Mike Frysinger
2007-06-29 0:39 ` Jiri Kosina
2007-06-29 2:01 ` Andrew Morton
2007-06-29 1:15 ` Andi Kleen
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=Pine.LNX.4.64.0706281850490.617@internets.corp.google.com \
--to=jwise@google.com \
--cc=akpm@linux-foundation.org \
--cc=kyle@mcmartin.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=masouds@google.com \
--cc=mikew@google.com \
--cc=thockin@google.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
all inboxes | Powered by JetHome®