Re: threshold_init_device/kobject_uevent_env oops

From: Greg KH
Date: Fri Jan 25 2008 - 18:10:00 EST


On Fri, Jan 25, 2008 at 11:35:56PM +0100, Ingo Molnar wrote:
>
> * Greg KH <gregkh@xxxxxxx> wrote:
>
> > On Fri, Jan 25, 2008 at 01:05:40PM -0800, Yinghai Lu wrote:
> > > current linus tree + x86.git
> > >
> > > got
> > >
> > > Calling initcall 0xffffffff80b93d98: threshold_init_device+0x0/0x3f()
> > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
> > > IP: [<ffffffff80458e20>] kobject_uevent_env+0x2a/0x3d9
> >
> > Does this happen on just Linus's tree?
> >
> > Can you send me a .config file for this?
> >
> > What is threshold_init()? Is it something new in the x86.git tree?
>
> no. A quick grep shows that it is in a file that _your_ changes in
> Linus' latest have touched:
>
> arch/x86/kernel/cpu/mcheck/mce_amd_64.c

In looking at this code some more, I'm a bit confused. We have an array
of kobjects in per_cpu(threshold_banks, cpu)[bank]->kobj

Now the kobject in the struct threshold_bank structure is a "static"
one, one that should govern the lifecycle of the object, yet there is no
release function for it at all. I don't see a way for it to ever be
properly torn down.

But it's the bank kobjects that are dynamic. They look to be created
properly, and the life cycle is correct because they are initialized by
the kobject core now correctly. But which order are things initialized
by the cpu code?

Ideally the banks are created before the blocks, but by the error
message that we have here, I'm not so sure about this. Can anyone
confirm this order is always correct?

Can someone send me the sysfs 'tree' output of what these kobjects are
supposed to be looking like?

Also, can someone enable CONFIG_KOBJECT_DEBUG and send me the output of
the startup of this code? That should help explain what order things
are happening it.

Actually the debug output with this oops would be great, it should show
the offending logic pretty well.

thanks,

greg k-h
--
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/