linux-kernel - Re: [Patch -mm 3/3] RFC: Introduce kobject->owner for refcounting.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Apr 2007 11:20:04 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Rusty Russell <rusty@...tcorp.com.au>
cc:	Cornelia Huck <cornelia.huck@...ibm.com>, Greg KH <greg@...ah.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Tejun Heo <htejun@...il.com>
Subject: Re: [Patch -mm 3/3] RFC: Introduce kobject->owner for refcounting.

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/