Re: must-fix, version 6

[Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>]

Hi Andrew,
hi Al,
hi LKML,

On Fri, May 30, 2003 at 04:37:20PM -0700, Andrew Morton wrote:
> +lib/kobject.c
> +~~~~~~~~~~~~~
> +
> +o kobject refcounting (comments from Al Viro):
> +
> +  _anything_ can grab a temporary reference to kobject.  IOW, if kobject is
> +  embedded into something that could be freed - it _MUST_ have a destructor
> +  and that destructor _MUST_ be the destructor for containing object.
> +
> +  Any violation of the above (and we already have a bunch of those) is a
> +  user-triggerable memory corruption.
> +
> +  We can tolerate it for a while in 2.5 (e.g.  during work on susbsystem we
> +  can decide to switch to that way of handling objects and have subsystem
> +  vulnerable for a while), but all such windows must be closed before 2.6 and
> +  during 2.6 we can't open them at all.
> +

I think a simple variant of this is to extend the kobject
structure with a backlink void* to the container of this object.

That way:
   - we can use kfree() as the default destructor 
   - use special destructors and pass the right object
   - warn and do the most useful thing (a kfree), until all 
     users are converted to either pass kfree or sth. else as an
     constructor.

This solution becomes non-sense, if we T <<< I, where T is the
amount of unique kobject type and I the sum of instances of all
types.

But even then, there can be a transitional model like the above,
but with a "default destructor" needing the container and the
kobject passed, which can later be reduced trivially to just have
the kobject passed and the container being caclulated with
"containerof" in the destructor with knowlegde about the type
where the kobject is in.

The latter solution needs lots of code to be written and is a
huge janitorial work. The backlink solution is much simpler, but
memory consuming.

Comments appreciated.

Regards

Ingo Oeser