On Thu, Dec 27, 2007 at 03:22:28PM -0800, Christoph Lameter wrote:Huh? Just call it from kmem_cache_destroy(); what business does that symlink have being around after that point? kobject_del() undoes the effect of kobject_add(). And then you are left with the refcount you had before kobject_add(), i.e. from kobject_init(). Think of it that way: kobject refcount controls the lifetime of structure the sucker's embedded into. Depending on kobject methods, you might be unable to do cleanup of non-kobject parts of that animal until after kobject_del(). IOW, you _can't_ have kobject_del() dropping the (hopefully) final reference to kobject - only the caller knows what might have to be done in between. --
| Cliffe | Re: [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning |
| Amit K. Arora | [RFC] Heads up on sys_fallocate() |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Andrew Morton | Re: [RFC/PATCH] Documentation of kernel messages |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Radu Rendec | Endianness problem with u32 classifier hash masks |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
git: | |
