Re: [PATCH RFD] alternative kobject release wait mechanism

[Cornelia Huck <cornelia.huck@de.ibm.com>]

On Sun, 22 Apr 2007 10:40:51 -0700,
Greg KH <greg@kroah.com> wrote:

> > Looking some more, kobject_get_path() is used for kobject renaming,
> > uevent handling, and a little bit in the input core.  None of these things 
> > should try to access a kobject after it has been del()ed.  After all, it's 
> > no longer present in the filesystem so it doesn't _have_ a path.
> 
> But we _have_ to have a full path at that time to tell userspace what
> just went away.  That is the main reason we enforce this (there were
> tons of issues with scsi devices and this in the past which is what
> caused us to enforce this.)

What we need to ensure is that the parent device is kept at least until
all children, grandchildren and so on are done with their uevent needs.
This would imply it needed to stay as long as those children,
grandchildren, ... are still registered. Would it be save to suggest
that a ->remove callback would always need to unregister the children?
Then putting the parent reference at the end of kobject_del() (which is
after kobject_uevent() in kobject_unregister()) should be safe.