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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/21/07, Greg KH <[email protected]> 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 <[email protected]> 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,

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.

> > 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?
[...]
So I'm guessing he was trying to catch something specific here.

Considering that:

(1) This isn't a bug that should bring down the kernel that hard, and,
(2) kobject_shadow_add() seems to be dumping enough stacks and
printing printk's on errors already,

I'd suggest to just get rid of the BUG_ON() in kernel_param_sysfs_setup()


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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux