Re: Fw: Re: 2.6.21-rc4-mm1 + 4 hotfixes -- BUG: unable to handle kernel paging request at virtual address 6b6b6ceb -- EIP is at module_put+0x7/0x1f

[Shaohua Li <shaohua.li@intel.com>]

On Wed, 2007-03-28 at 14:49 +0800, Shaohua Li wrote:
> On Tue, 2007-03-27 at 22:58 -0700, Greg KH wrote:
> > On Wed, Mar 28, 2007 at 01:39:26PM +0800, Shaohua Li wrote:
> > > On Tue, 2007-03-27 at 22:27 -0700, Greg KH wrote:
> > > > 
> > > > Putting more than one kobject in the same structure is a broken design.
> > > > How can you control the lifetime rules properly if there are two
> > > > reference counts for the same structure?  It doesn't work.
> > > > 
> > > > If you really need something like this, then just use a pointer to a
> > > > kobject for one of them instead of embedding it.  Why do you need two
> > > > different kobjects here?
> > > Our data structure is something like below:
> > > 
> > > struct foo {
> > > 	kobject kobja;
> > > }
> > > 
> > > struct bar {
> > > 	struct foo foo[];
> > 
> > Ick, don't do that...
> why?
Greg, can you share why don't do that? Or I can assume the patch is ok
to push to len?

> > > 	kobject kobjb
> > > }
> > > 
> > > kobjb's .release will free struct bar. kobjb is the parent of kobja. if
> > > you have a reference on kobja, then kobjb can't be released too, right?
> > > So we only kobjb provide a .release to free the memory, kobja's .release
> > > isn't required.
> > 
> > Why not just use the "normal" parent/child relationship with the
> > kobjects like the rest of the kernel does?
> I still didn't get the reason why we couldn't do this in the way of my
> patch. As I said, there isn't risk to use 'freed memory'. I can make the
> 'struct foo' a pointer, but this will mess the cpuidle driver.
> 
> Thanks,
> Shaohua