linux-kernel - Two unclear places in lockdep-design.txt

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>] [day] [month] [year] [list]

Date:	Wed, 14 Feb 2007 21:36:58 -0500
From:	Pavel Roskin <proski@....org>
To:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>
Subject: Two unclear places in lockdep-design.txt

Hello, Ingo!

Many thanks for the lockdep validator!  It has helped me immensely.
However, lockdep-design.txt has been pretty hard to read for me.

It would be great if you find an opportunity to clarify two things in
the documentation.

1) What is a lock dependency?  What does "L1 -> L2" mean?  Does it mean
that L1 should be first or second to be acquired?

2) What is "ever held with hardirqs enabled"?  Does it mean that the
lock was used in the code where hardirqs were enabled, or that it _also_
didn't disable hardirqs by itself (e.g. by spin_lock_irq)?  I suspect
the later is the case.

I wish I could submit a patch for the documentation, but I still don't
understand much of the theory.  Still, I was able to interpret the error
messages in a way that allows me to fix the locking issues in some
drivers.

-- 
Regards,
Pavel Roskin

-
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/