Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 1d4093d3 authored by Eric Engestrom's avatar Eric Engestrom Committed by Ingo Molnar
Browse files

locking/Documentation/lockdep: Fix spelling mistakes 



Signed-off-by: default avatarEric Engestrom <eric@engestrom.ch>
Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1461566229-4717-2-git-send-email-eric@engestrom.ch


Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
parent c003ed92

Documentation/locking/lockdep-design.txt

+2 −2
Original line number Diff line number Diff line
@@ -97,7 +97,7 @@ between any two lock-classes: 
   <hardirq-safe>   ->  <hardirq-unsafe>

   <softirq-safe>   ->  <softirq-unsafe>



The first rule comes from the fact the a hardirq-safe lock could be

The first rule comes from the fact that a hardirq-safe lock could be

taken by a hardirq context, interrupting a hardirq-unsafe lock - and

thus could result in a lock inversion deadlock. Likewise, a softirq-safe

lock could be taken by an softirq context, interrupting a softirq-unsafe
@@ -220,7 +220,7 @@ calculated, which hash is unique for every lock chain. The hash value, 
when the chain is validated for the first time, is then put into a hash

table, which hash-table can be checked in a lockfree manner. If the

locking chain occurs again later on, the hash table tells us that we

dont have to validate the chain again.

don't have to validate the chain again.



Troubleshooting:

----------------