On Wed, 2007-04-18 at 11:20 -0400, Alan Stern wrote: > On Wed, 18 Apr 2007, Rusty Russell wrote: > > > Hi Alan, > > > > Your assertion is correct. I haven't studied the driver core, so I > > might be off-base here, but you'll note that if the module references > > the core kmalloc'ed object rather than the other way around it can be > > done safely. The core can also reference the module, but it must be > > able to live without it once it's gone (eg. by returning -ENOENT). > > "Live without it once it's gone..." Do you mean once the object is gone > or once the module is gone? The core in general has no way to know when > the module is gone; all it knows about is the object. The trouble arises > when the module is gone (whether the core knows it or not) but the object > is still present.
Hi Alan, I meant that the module is gone: it has told the object (via unregister_xxx) that it's gone. > > A really poor example is below: ... > The example is fine as far as it goes, but it assumes that all > interactions with the underlying r->foo object can be done under a > spinlock. Of course this isn't true in general. There are certainly other ways of doing it, such as a mutex, a refcnt & completion (for function pointers), or disabling preemption across the access and using stop_machine(). Of course, these add complexity. This is the reason that I've always disliked module removal. We have a lot of code to deal with it and it has awkward semantics (unless --wait is used). OTOH, I'm not a fan of the network approach, either: I feel that bringing up an interface should bump the refcnt of the module which implements that interface. Currently taking out e1000 will just kill my eth0. Cheers, Rusty. > > Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/