Re: [linux-usb-devel] [PATCH] back out sysfs reference count change

[Maneesh Soni]

On Wed, Mar 31, 2004 at 10:11:37AM -0500, Alan Stern wrote:
> On Wed, 31 Mar 2004, Maneesh Soni wrote:
> 
> > For convenience I will explain the race here..
> > 
> > cpu 0							cpu 1
> > kobject_unregister()				   sysfs_open_file()
> >   kobject_del()					     check_perm()
> >     sysfs_remove_dir()					   :
> >      (dentry remains alive due to ref. taken 		   :
> >       on the way to sysfs_open_file)			   :
> >   kobject_put()					   	   :
> >     kobject_cleanup()					kobject_get(->d_fsdata)
> > 
> > cpu 1 could end up referring to a freed kobject through dentry->d_fsdata or
> > starts spitting Badness in kobject_get at lib/kobject.c:429. For triggering 
> > this race try running these two loops simultaneously on SMP 
> > 
> > # while true; do insmod drivers/net/dummy.ko; rmmod dummy; done
> > # while true; do find /sys/class/net | xargs cat; done
> > 
> > Probably it can be solved by making sure that when sysfs file is 
> > opened/read/written some _race_ free check is done and fail if kobject if gone. 
> > 
> > Maneesh
> 
> Here's a suggestion.  At the start of check_perm() grab the dentry 
> semaphore, then check whether d_fsdata is NULL, if it isn't then do the 
> kobject_get(), then unlock the semaphore.
> 

I have tried this with no luck. I still get 
(Badness in kobject_get at lib/kobject.c:42) which means it is not correct fix.

I am out of any more ideas except something like making sysfs single threaded 
or requesting people to try my sysfs backing store patch set. It does not
suffer from the negative dentries problem as it does not create any negative
dentries. I have to re-diff the patch set again to take recent changes into
account.

Maneesh



-- 
Maneesh Soni
Linux Technology Center, 
IBM Software Lab, Bangalore, India
email: maneesh@xxxxxxxxxx
Phone: 91-80-25044999 Fax: 91-80-25268553
T/L : 9243696
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/