lkml.org 
[lkml]   [2007]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570
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 !? Shouldn't that turn up pretty quickly in a grep?

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

\
 
 \ /
  Last update: 2007-07-21 02:07    [W:0.461 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site