Re: Question about (or bug in?) the kobject implementation

From: Alan Stern (stern_at_rowland.harvard.edu)
Date: 02/27/04

  • Next message: Christophe Saout: "Re: [PATCH/proposal] dm-crypt: add digest-based iv generation mode" 
    Date:	Fri, 27 Feb 2004 15:06:32 -0500 (EST)
To: Greg KH <greg@kroah.com>

    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/

  • Next message: Christophe Saout: "Re: [PATCH/proposal] dm-crypt: add digest-based iv generation mode"

    Relevant Pages