[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070423090810.2fc0e864@gondolin.boeblingen.de.ibm.com>
Date: Mon, 23 Apr 2007 09:08:10 +0200
From: Cornelia Huck <cornelia.huck@...ibm.com>
To: Greg KH <greg@...ah.com>
Cc: Alan Stern <stern@...land.harvard.edu>,
Tejun Heo <htejun@...il.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Rusty Russell <rusty@...tcorp.com.au>,
Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [PATCH RFD] alternative kobject release wait mechanism
On Sun, 22 Apr 2007 10:40:51 -0700,
Greg KH <greg@...ah.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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists