On Mon, May 19, 2008 at 6:23 PM, Matthew Wilcox <matthew@xxxxxx> wrote: > On Mon, May 19, 2008 at 01:20:33PM +0800, Dave Young wrote: >> 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. > > The question isn't whether there is or isn't this kind of use right now. > The question is whether there might be this kind of use in the future, > and if there is, whether we'd like lockdep to warn us. In the future, IMHO, the class_interface should go away just as class_device. If that happened this problem would going away as well. > >> 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? > > Again, it's not about current usage, it's about future usage. Why do > you want all sysfs classes to have the same lockdep class? There can > be good reasons. For example, if two locks are conceptually the same, > keeping them in the same class helps you find AB-BA problems earlier. > > Is there a reason you don't like my idea? Your idea is good. But as I said above, for current situation there's no potential problems except class_interface usage, and the class_interface will go away in the future. So IMO It's not necessary to do this for all classes. Regards dave -- 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
