Messages in this thread | | | Date | Fri, 27 Feb 2004 15:06:32 -0500 (EST) | From | Alan Stern <> | Subject | Re: Question about (or bug in?) the kobject implementation |
| |
On Fri, 27 Feb 2004, Greg KH wrote:
> On Wed, Feb 25, 2004 at 10:05:37AM -0500, Alan Stern wrote: > > Is it supposed to be legal to repeatedly call kobject_add() and > > kobject_del() for the same kobject? That is, is > > > > kobject_add(&kobj); > > ... > > kobject_del(&kobj); > > ... > > kobject_add(&kobj); > > ... > > kobject_del(&kobj); > > > > supposed to work? > > No. > > > The API doesn't forbid it, and there's no apparent reason why it > > should be illegal. > > We prevent race conditions in kobject_put() by saying "Don't do that!" > :) > > Seriously, once kobject_del() is called, you can't safely call > kobject_get() anymore on that object.
Are you worried about the possibility of the refcount dropping to 0 and the cleanup starting but then kobject_get() increasing the refcount again? Or is there some other problem?
> If you can think of a way we can implement this in the code to prevent > people from doing this, please send a patch. We've been getting by > without such a "safeguard" so far...
Maybe I could if I knew more clearly the exact issue in question.
> > Why would anyone want to do this, you ask? Well the USB subsystem does it > > already. Each USB device can have several configurations, only one of > > which is active at any time. Corresponding to each configuration is a set > > of struct devices, and they (together with their embedded kobjects) are > > allocated and initialized when the USB device is first detected. The > > struct devices are add()'ed and del()'ed as configurations are activated > > and deactivated, leading to just the sort of call sequence shown above. > > Then we need to fix this.
As it happens, I have a patch to do that. :-) I'll send it in a separate message.
Alan Stern
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |