linux-kernel - Re: lockdep warning for iscsi in 2.6.33-rc6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B7200DC.60103@oracle.com>
Date:	Wed, 10 Feb 2010 08:42:04 +0800
From:	Tao Ma <tao.ma@...cle.com>
To:	Mike Christie <michaelc@...wisc.edu>
CC:	open-iscsi@...glegroups.com, linux-kernel@...r.kernel.org
Subject: Re: lockdep warning for iscsi in 2.6.33-rc6

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.
> 
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/