[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20110310143806.7542e929.akpm@linux-foundation.org>
Date: Thu, 10 Mar 2011 14:38:06 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Phil Carmody <ext-phil.2.carmody@...ia.com>
Cc: gregkh@...e.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv3 1/1] sysfs: add more info to the oops dump
On Fri, 11 Mar 2011 00:27:07 +0200
Phil Carmody <ext-phil.2.carmody@...ia.com> wrote:
> +static int last_sysfs_write_len;
> void sysfs_printk_last_file(void)
> {
> - printk(KERN_EMERG "last sysfs file: %s\n", last_sysfs_file);
> + printk(KERN_EMERG "last sysfs file (%c): %s%c",
> + (last_sysfs_write_len == SYSFS_NOT_A_WRITE) ? 'r' : 'w',
> + last_sysfs_file,
> + last_sysfs_write_len > 0 ? ' ' : '\n');
> + if (last_sysfs_write_len >= (int)sizeof(last_sysfs_write))
> + printk(KERN_CONT " written: %s...(%d chars)\n",
> + last_sysfs_write, last_sysfs_write_len);
> + else if (last_sysfs_write_len > 0)
> + printk(KERN_CONT " written: %s\n", last_sysfs_write);
> }
That's going to fail to emit the \n if last_sysfs_write_len<=0.
However there are tricks inside printk() which will fix that up if the
next printk starts with KERN_foo.
I can recall just one instance in the past 5-6 years in which the
last-sysfs-file output enabled me to locate a bug which would otherwise
have been unlocatable (within a drivers/md handler, iirc).
I don't think it's a terribly useful feature. Except for when it _is_
useful, when it's very useful ;) The world wouldn't end if we decided
to remove it.
--
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/
Powered by blists - more mailing lists