lockdep warning for iscsi in 2.6.33-rc6
Mike Christie
> Hi Mike,
> I meet with a lockdep warning for iscsi in 2.6.33-rc6.
> the lockdep is attached.
>
If the lockdep output is saying that there is a problem with the iscsi
host taking its mutex then the scsi host mutex, I think that might be a
mistake in the lockdep detection. We always take the iscsi host mutex
then take the scsi host mutex.
Could it get confused if we are scanning two hosts at the same time? If
it is just looking at if a lock is being taken then it would look like
host1 has its ihost->mutex and then took its shost->mutex, but then
host2 could start to get scanned at the same time, and it is going to
take its ihost->mutex. It would then look like we are trying to grab a
ihost->mutex while holding a shost->mutex. However, the mutexs are not
global and they are different instances of the mutex because each host
has its own.
If that is not the problem, maybe it has something to do with some sysfs
lock and ata doing scanning while iscsi is.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Tao Ma
Mike Christie wrote:
> On 02/09/2010 12:59 AM, Tao Ma wrote:
>> Hi Mike,
>> I meet with a lockdep warning for iscsi in 2.6.33-rc6.
>> the lockdep is attached.
>>
>
> If the lockdep output is saying that there is a problem with the iscsi
> host taking its mutex then the scsi host mutex, I think that might be a
> mistake in the lockdep detection. We always take the iscsi host mutex
> then take the scsi host mutex.
>
> Could it get confused if we are scanning two hosts at the same time? If
> it is just looking at if a lock is being taken then it would look like
> host1 has its ihost->mutex and then took its shost->mutex, but then
> host2 could start to get scanned at the same time, and it is going to
> take its ihost->mutex. It would then look like we are trying to grab a
> ihost->mutex while holding a shost->mutex. However, the mutexs are not
> global and they are different instances of the mutex because each host
> has its own.
If these 2 mutexes are grabed in the same order(in your description,
ihost->mutex first and then shost->mutex), there would be no problem.
>
> If that is not the problem, maybe it has something to do with some sysfs
> lock and ata doing scanning while iscsi is.
yeah it looks so from the lockdep output.
You know the real bad thing is that after lockdep find an error, it will
set debug_locks to 0, so any future check will be disabled. As iscsi
start up very early, no other check can be proceeded.
Regards,
Tao
Maciej Rutecki
I created a Bugzilla entry at http://bugzilla.kernel.org/show_bug.cgi?id=15278
for Your bug report, please add Your address to the CC list in there, thanks!
--
Maciej Rutecki
http://www.maciek.unixy.pl
Mike Christie
> Hi Mike,
>
> Mike Christie wrote:
>> On 02/09/2010 12:59 AM, Tao Ma wrote:
>>> Hi Mike,
>>> I meet with a lockdep warning for iscsi in 2.6.33-rc6.
>>> the lockdep is attached.
>>>
>>
>> If the lockdep output is saying that there is a problem with the iscsi
>> host taking its mutex then the scsi host mutex, I think that might be
>> a mistake in the lockdep detection. We always take the iscsi host
>> mutex then take the scsi host mutex.
>>
>> Could it get confused if we are scanning two hosts at the same time?
>> If it is just looking at if a lock is being taken then it would look
>> like host1 has its ihost->mutex and then took its shost->mutex, but
>> then host2 could start to get scanned at the same time, and it is
>> going to take its ihost->mutex. It would then look like we are trying
>> to grab a ihost->mutex while holding a shost->mutex. However, the
>> mutexs are not global and they are different instances of the mutex
>> because each host has its own.
> If these 2 mutexes are grabed in the same order(in your description,
> ihost->mutex first and then shost->mutex), there would be no problem.
I checked the code and we are taking the locks in the proper order, but
I did some more testing and I do not think it was detecting what I
thought above.
I just did a login with one iscsi session and got the lockdep warning.
So I will do some more digging into what is going on.