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.
> A really poor example is below:
>
> int register_foo(struct foo *foo)
> {
> struct registered_foo *r = kmalloc(...);
> if (!r)
> return -ENOMEM;
> r->foo = foo;
> atomic_set(&r->refcnt, 1);
> spin_lock(&foo_lock);
> list_add(&foos, &r->list);
> spin_unlock(&foo_lock);
> return 0;
> }
>
> void unregister_foo(struct foo *foo)
> {
> struct registered_foo *i, *found = NULL;
> spin_lock(&foo_lock);
> list_for_each_entry(i, &foos, list) {
> if (i->foo == foo) {
> i->foo = NULL;
> if (atomic_dec_and_test(&i->refcnt))
> kfree(i);
> break;
> }
> }
> spin_unlock(&foo_lock);
> }
>
> int get_foo_value(struct registered_foo *r)
> {
> u32 val = -ENOENT;
> spin_lock(&foo_lock);
> if (r->foo)
> val = r->foo->val;
> spin_unlock(&foo_lock);
> return val;
> }
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.
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/
