On Mon, 16 Apr 2007 10:43:01 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> Actually it has to be done in kobject_init() since the release method can > be called any time after that, even if the kobject is never add'ed. True. This would also imply that we only ever must free a kobject with kobject_put() if kobject_init() has been called. > > > from now on it may be looked up). kobject_get()/kobject_put() wouldn't > > need to grab an extra reference (we already have refcounting for this > > object in place). kobject_cleanup() could do something like: > > > > struct module * kobject_owner = kobj->owner; > > ... > > call_release(); > > put_second_module_refcount(kobject_owner); > > > > combined with the module unloading code waiting after calling the exit > > function until the second type refcount dropped to 0. This would make > > sure that the module is not deleted until the last release function has > > been called. > > > > The module would stay in memory (not be unloaded) until the last > > kobject created by the module is deleted, but I think that is just what > > we want. At least this doesn't mean that the module blocks its own > > unloading. > > Yes, that's what I had in mind. > > It would have to apply to other things besides kobjects -- in principle, > anything with a release routine, although in many cases it wouldn't be > needed. But in particular, it _would_ be needed for struct device. > > (In fact, perhaps kobject would not need it. There aren't too many places > where a raw kobject is used; almost always it is embedded in some larger > object -- like struct device -- along with a release method pointer. > This larger object would need an owner but its embedded kobject usually > would not.) Yes, struct device might be enough for most use cases. However, this would involve looking hard at the code :) > > On the other hand, this proposal involves adding a fair amount of overhead > (all those .owner fields) for a rather small benefit. And it involves > modifying a core kernel subsystem (kernel/module.c). All to prevent > certain unlikely sorts of errors when removing a module -- something which > Linus has said repeatedly need not be supported terribly well. The basic infrastructure isn't too hard (I'm having a patch using mkobj on my disk that is in nearly workable state). And I think that this is something that really should be fixed - it is just way too easy for a driver writer to mess this up (and the race window becomes even bigger on virtualized platforms). - 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/
