On Mon, May 19, 2008 at 1:20 PM, Dave Young <hidave.darkstar@xxxxxxxxx> 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.
>>>
>>> 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?
>
Like this?
1) Add macro :
+#define class_reclassify(class) \
+do { \
+ static struct lock_class_key class_key; \
+ lockdep_set_class_and_name(&(class)->mutex, &class_key, \
+ (class)->name); \
+} while (0)
2) Then in sg.c:
class_reclassify(sg_sysfs_class);
3) And in pcmcia/cs.c
class_reclassify(&pcmcia_socket_class);
I have built and boot tested the patch, but due to connecting gmail
smtp failed so I cant send it via mutt today.
--
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
