On Sat, May 17, 2008 at 6:14 PM, Dave Young <hidave.darkstar@xxxxxxxxx> wrote: > On 5/15/08, Matthew Wilcox <matthew@xxxxxx> wrote: >> On Thu, May 15, 2008 at 05:01:01PM +0800, Dave Young wrote: >>> > The classes are different here, first sdev_class, then sg_sysfs_class >> >> Oh ... right. I misread scsi_register_interface as >> class_register_interface. >> >>> Greg, what about using mutex_lock_nested to silence lockdep? They are >>> the only usage of class->mutex out of class.c >> >> I don't see how we prove that, for example, you can never take the >> sg_sysfs_class mutex and then take the sdev_class mutex. > > Sorry for my delay. AFAIK, there's no this kind of use. >> >> There aren't /that/ many classes in the kernel (my laptop has 33 in >> /sys/class). How about we make each (sysfs) class its own (lockdep) >> class? That way we let lockdep do its job rather than telling it "nah, >> you're all right, this is good". >> >> I don't have a copy of the sem->mutex conversion to hand, but I imagine >> you want to do something like: >> >> - Add a struct lock_class_key to struct class >> - In drivers/base/class.c use __mutex_init instead of mutex_init >> >> I think that should be enough ... > > Yes, it's safer than mutex_lock_nested. If you all have no objection > I can do the fix like this. > I rechecked the class_interface use, the users are scsi and pcmcia. The two classes could call device_add/del while doing class_interface_register/unregister is : sg_sysfs_class pcmcia_socket_class So is it possible to reset their lock_class instead of do __mutex_init for all classes? -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
