Re: [PATCHv3 1/1] sysfs: add more info to the oops dump

[Thomas Gleixner <tglx@linutronix.de>]

On Fri, 11 Mar 2011, Phil Carmody wrote:
> On 10/03/11 23:59 +0100, ext Thomas Gleixner wrote:
> > On Thu, 10 Mar 2011, Andrew Morton wrote:
> > 
> > > On Fri, 11 Mar 2011 00:27:07 +0200
> > > Phil Carmody <ext-phil.2.carmody@nokia.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. 
> 
> That's this case:
> + 	       last_sysfs_write_len > 0 ? ' ' : '\n');
> 
> > > 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.
> > 
> > Amen to that.
> > 
> > It's more of an distraction than anything which is relevant to 99.999%
> > of the problems we have to deal with.
> 
> As I indicated before, I've previously thought that too, but thought I
> could 'fix' it by adding to it when I hit the once-in-three-years case.

The interesting question is:

 How did that info help and was it really the ultimate reason why you
 found the underlying bug ?

Thanks,

	tglx