On Tue, 2007-04-17 at 12:08 -0400, Alan Stern wrote:
> More specifically, there _is_ no way in general to ensure that a reference
> will go away when the module's cleanup routine is called, unless you are
> very careful not to pass that reference on to _anybody_. The driver core
> certainly can't do this; it passes a device reference to anyone who
> creates a child of that device (the parent pointer) -- and it can't
> guarantee that every one of its clients will drop their references when
> their exit routines run.
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).
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;
}
> I'm not so sure I fully believe that network drivers can do what Rusty
> says, at least not in every circumstance. There simply are too many
> possible ways for references to linger on after you thought they were all
> gone. For example, what happens when the user has mounted a filesystem on
> a USB drive running via USB-over-TCP though a network interface?
That's actually fine, it's when packets linger in the system holding
references to the interface they came from that things get tricky.
Hence the networking code tries not to do that.
Cheers,
Rusty.
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
