Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

Greg KH
2007-07-21T01:03:50Z

On Sat, Jul 21, 2007 at 02:28:52AM +0200, Michal Piotrowski wrote:
> On 21/07/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> > Oh, which means ...
> >
> >
> > On 7/21/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> > > On 7/21/07, Greg KH <gregkh@suse.de> wrote:
> > > > 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@suse.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);
> >
> > Shouldn't the return of kobject_set_name() be checked here?
> >
> > [ Looking at code, and realizing that kobject_set_name() manages to
> > succeed even when given a null string! ]
> >
> > > > > > > 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,
> > >
> > > I don't think that's an -EEXIST.
> > >
> > > I think what we have here is kobject_add() exiting with -EINVAL.
> > > (kobject attempted to be registered with no name!)
> > >
> > > [ The first trace on that screen shows: kobject_shadow_add+0x5b/0x189.
> > > That's the WARN_ON(1) at lib/kobject.c:176. If it was a EEXIST case,
> > > we would've seen an offset in kobject_shadow_add closer to 0x189,
> > > because the dump_stack() for EEXIST is barely 4 instructions before
> > > we return from that function. ]
> > >
> > > > > > but the trick is going to be
> > > > > > trying to figure out what module is causing this.
> > >
> > > So I'd guess we want to search for a module that's passing a kobject *
> > > to kobject_add() such that !kobj->k_name is true.
> >
> > Oh, that's kernel_param_sysfs_setup itself. So we actually need to
> > search for a built-in module in Michal's config that ... has an ... empty
> > "" modname !?
>
> I'll try to figure out this

Try the patch below to help you boot and figure out what went wrong.

Post the kernel log results and I'll try to help you out.

thanks,

greg k-h

---
kernel/params.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

--- a/kernel/params.c
+++ b/kernel/params.c
@@ -567,7 +567,11 @@ static void __init kernel_param_sysfs_se
kobject_set_name(&mk->kobj, name);
kobject_init(&mk->kobj);
ret = kobject_add(&mk->kobj);
- BUG_ON(ret < 0);
+ if (ret) {
+ printk(KERN_ERR "module '%s' failed to be added to sysfs, "
+ "the system will be unstable now.\n", name);
+ return;
+ }
param_sysfs_setup(mk, kparam, num_params, name_skip);
kobject_uevent(&mk->kobj, KOBJ_ADD);
}