All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Joshua Wise <jwise@google.com>
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 16:48:55 -0700	[thread overview]
Message-ID: <20070628164855.012344cd.akpm@linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0706281603590.617@internets.corp.google.com>

On Thu, 28 Jun 2007 16:12:23 -0700 (PDT)
Joshua Wise <jwise@google.com> wrote:

> Version: 2
> 
> Background:
>   When managing a large number of servers, as Google does, it's sometimes
>   useful to get an "at-a-glance" view of a machine when it crashes. When no
>   other post-mortem is possible, it's often useful to know how long the
>   machine has been powered on, which kernel it was running, and possibly
>   other information that a driver may have logged. Up until now, there was no
>   real way to do this other than to keep statistics outside to the machine.
> 
> Description:
>   This patch adds a call chain to be invoked when the system oopses or
>   panics. Traps have been added to i386 and x86_64 kernels, but it should be
>   trivial to add support for more architectures. Two sample notifiers have
>   been added -- an uptime printer, and a utsname printer for showing various
>   statistics about the running system.
> 
> Remaining issues:
>   * Is do_posix_clock_monotonic_gettime really the right API?
>   * Should this be on by default, or a disablable Kconfig entry?
> 
> Testing:
>   I accidentally built my testing kernel without the IDE drivers. It panic()ed
>   immediately, and informed me that my uptime was 0.38 seconds.
> 
> Credits:
>   This code was mainly written by Mike Waychison <mikew@google.com> and
>   Masoud Sharbiani <masouds@google.com>.
> 
> Changelog:
>   v2 -- fixed some checkpatch issues. Moved dumping to before Oopses, as per
>   the suggestion of Kyle McMartin <kyle@mcmartin.ca>.
> 
> diff --git a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c
> index 06dfa65..f969c04 100644
> --- a/arch/i386/kernel/process.c
> +++ b/arch/i386/kernel/process.c
> @@ -301,6 +301,8 @@ void show_regs(struct pt_regs * regs)
>   {

Your email client is doing space-stuffing.  It's easy enough to fix at this
end, but even easier if you fix it ;)

>   	unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;
> 
> +	atomic_notifier_call_chain(&info_dumper_list, 0, NULL);
> +

I worry a bit about doing _anything_ extra at oops-time.  It just decreases
the chances of the kernel generating the info which we want.

So...  Please consider abandoning the notifier-chain and just go for a
simple function call.

If people want to add extra goodies later on, well, they need to patch the
kernel anyway so they can patch your newly-added function rather than
hooking into the notifier chain.


>   EXPORT_SYMBOL(cad_pid);
> 
>   /*
> + *	Notifier list for kernel code which wants to printk hardware specific
> + *	information at Oops or panic time.
> + */
> +
> +ATOMIC_NOTIFIER_HEAD(info_dumper_list);
> +EXPORT_SYMBOL(info_dumper_list);

That export isn't needed.

> +/*
> + * Dump out UTS info on oops / panic.
> + */
> +
> +static int dump_utsname(struct notifier_block *self, unsigned long v, void *p)
> +{
> +	printk (KERN_EMERG "%s %s %s %s %s %s\n",
> +		utsname()->sysname,
> +		utsname()->nodename,
> +		utsname()->release,
> +		utsname()->version,
> +		utsname()->machine,
> +		utsname()->domainname);
> +	return 0;
> +}

Again, a deref of current->nsproxy->uts_ns->name at oops-time has risks.

This string could be precalculated, no?

> +static struct notifier_block utsname_notifier;
> +
> +static int __init register_utsname_dump(void) {

<wishes that all nooglers got a copy of K&R>

> +	utsname_notifier.notifier_call = dump_utsname;
> +	atomic_notifier_chain_register(&info_dumper_list, &utsname_notifier);
> +	return 0;
> +}
> +__initcall(register_utsname_dump);

module_init() is a bit more modern, but equivalent.

> +/*
> + * Dump out uptime info on oops / panic.
> + *
> + * FIXME: Should I be just using get_jiffies64()? what if the lock there
> + * is damaged beyond any recognition?
> + */
> +
> +static int dump_uptime(struct notifier_block *self, unsigned long v, void *p)
> +{
> +	struct timespec uptime;
> +	/* The logic below is very much like how kernel
> +	 * prepares /proc/uptime.
> +	 */
> +	do_posix_clock_monotonic_gettime(&uptime);
> +	printk(KERN_EMERG "Uptime (seconds): %lu.%02lu\n",
> +		(unsigned long) uptime.tv_sec,
> +		(uptime.tv_nsec / (NSEC_PER_SEC / 100)));
> +
> +	return 0;
> +}

do_posix_clock_monotonic_gettime() takes xtime_lock.  So if the kernel
oopses while holding xtime_lock we don't get to see the oops.  This is bad.

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.

> +static struct notifier_block uptime_notifier;
> +
> +static int __init register_uptime_dump(void) {

thwap

> +	uptime_notifier.notifier_call = dump_uptime;
> +	atomic_notifier_chain_register(&info_dumper_list, &uptime_notifier);
> +	return 0;
> +}
> +__initcall(register_uptime_dump);

module_init()

  reply	other threads:[~2007-06-28 23:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-28 22:05 [PATCH] Info dump on Oops or panic() 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 [this message]
2007-06-29  2:15       ` Joshua Wise
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=20070628164855.012344cd.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=jwise@google.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.