Re: 2.5.67-mm3: Bad: scheduling while atomic with IEEE1394 then hard

[Patrick Mochel]

> Hm yeah, this will fix the problem.  But is there anyway we can do this
> without a lock at all?  I think we wouldn't need the lock, if we didn't
> test the refcount for > 0, right?  Pat, that just keeps us from getting
> a reference count on a kobject that hasn't been initialized, right?
> That is a good idea to do, but is it really necessary?

Well, it also prevents us from getting a reference to an object that is 
being deleted. The chance of that happening is slim, and it indicates a 
need for synchronization at a higher level (if the kobject_get() on the 
object being deleted was to be delayed for some reason, they would likely 
be referencing freed memory anyway). 

And, in theory, an uninitialized object shouldn't be accessible, and any 
code doing that is buggy, and will have other problems. 

In short, I think we can remove the locks entirely. We can at least see 
what happens.. 

	-pat

===== lib/kobject.c 1.19 vs edited =====
--- 1.19/lib/kobject.c	Sat Apr 12 16:20:38 2003
+++ edited/lib/kobject.c	Wed Apr 16 09:57:15 2003
@@ -9,8 +9,6 @@
 #include <linux/module.h>
 #include <linux/stat.h>
 
-static spinlock_t kobj_lock = SPIN_LOCK_UNLOCKED;
-
 /**
  *	populate_dir - populate directory with attributes.
  *	@kobj:	object we're working on.
@@ -336,12 +334,10 @@
 struct kobject * kobject_get(struct kobject * kobj)
 {
 	struct kobject * ret = kobj;
-	spin_lock(&kobj_lock);
-	if (kobj && atomic_read(&kobj->refcount) > 0)
+	if (kobj)
 		atomic_inc(&kobj->refcount);
 	else
 		ret = NULL;
-	spin_unlock(&kobj_lock);
 	return ret;
 }
 
@@ -371,10 +367,8 @@
 
 void kobject_put(struct kobject * kobj)
 {
-	if (!atomic_dec_and_lock(&kobj->refcount, &kobj_lock))
-		return;
-	spin_unlock(&kobj_lock);
-	kobject_cleanup(kobj);
+	if (atomic_dec_and_test(&kobj->refcount))
+		kobject_cleanup(kobj);
 }