[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070720231052.GA19752@suse.de>
Date: Fri, 20 Jul 2007 16:10:52 -0700
From: Greg KH <gregkh@...e.de>
To: Andrew Morton <akpm@...ux-foundation.org>, rdunlap@...otime.net
Cc: Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570
On Fri, Jul 20, 2007 at 03:59:12PM -0700, Andrew Morton wrote:
> On Fri, 20 Jul 2007 15:50:47 -0700
> Greg KH <gregkh@...e.de> wrote:
>
> > On Fri, Jul 20, 2007 at 06:32:21PM +0200, Michal Piotrowski wrote:
> > > Hi Greg,
> > >
> > > This looks like a sysfs bug
> > > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-07-20-00-22/00003.jpg
> > >
> > > l *kernel_param_sysfs_setup+0x75
> > > 0xc13c0894 is in kernel_param_sysfs_setup (kernel/params.c:570).
> > > 565 mk->mod = THIS_MODULE;
> > > 566 kobj_set_kset_s(mk, module_subsys);
> > > 567 kobject_set_name(&mk->kobj, name);
> > > 568 kobject_init(&mk->kobj);
> > > 569 ret = kobject_add(&mk->kobj);
> > > 570 BUG_ON(ret < 0);
> > > 571 param_sysfs_setup(mk, kparam, num_params, name_skip);
> > > 572 kobject_uevent(&mk->kobj, KOBJ_ADD);
> > > 573 }
> > > 574
> > >
> > > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-07-20-00-22/mm-config
> >
> > What kernel version is this happening on? The -mm tree? Can you try
> > Linus's tree instead?
> >
> > It looks like there was some needed information right before the first
> > stack dump, showing exactly what kobject was trying to be added that was
> > already present. Odds are this is a kernel parameter with the same name
> > as a duplicate one within the same module, but the trick is going to be
> > trying to figure out what module is causing this.
> >
> > So it's not a sysfs bug, but rather a driver issue that this is
> > catching.
>
> In that case a BUG was way too harsh treatment, and in fact directly
> contributed to our inability to debug the bug!
>
> Can we wind that back a bit? Add some useful printks and then recover
> in some fashion?
Sure, I don't mind doing that at all.
Hm, it looks like Randy added this back in September last year with:
commit d8c7649e99e4b081b624aefe1e77caa30b53cb18
Author: Randy Dunlap <rdunlap@...otime.net>
Date: Fri Sep 29 01:58:55 2006 -0700
[PATCH] kernel/params: driver layer error checking
Check driver layer return values in kernel/params.c
Signed-off-by: Randy Dunlap <rdunlap@...otime.net>
Signed-off-by: Andrew Morton <akpm@...l.org>
Signed-off-by: Linus Torvalds <torvalds@...l.org>
(wow, I love git and the signed-off-tree for things like this, it's
trivial to find this information out.)
So I'm guessing he was trying to catch something specific here.
Randy, any objection to changing that BUG_ON to a printk warning instead
telling the user exactly what needs to be fixed and that the system is
now going to be unstable when any module is unloaded?
thanks,
greg k-h
-
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