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

[Greg KH]

On Sat, Jul 21, 2007 at 02:28:52AM +0200, Michal Piotrowski wrote:
>  On 21/07/07, Satyam Sharma <satyam.sharma@xxxxxxxxx> wrote:
> > Oh, which means ...
> >
> >
> > On 7/21/07, Satyam Sharma <satyam.sharma@xxxxxxxxx> wrote:
> > > On 7/21/07, Greg KH <gregkh@xxxxxxx> 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@xxxxxxx> 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);
 }

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/