redonkable
/
remarkable-linux
1
0
Fork 0
Code Releases Activity

locking/Documentation/lockdep: Fix spelling mistakes 

Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Signed-off-by: Peter 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: Ingo Molnar <mingo@kernel.org>
steinar/wifi_calib_4_9_kernel
Eric Engestrom 2016-04-25 07:36:54 +01:00 committed by Ingo Molnar
parent c003ed9289
commit 1d4093d3b3
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Documentation/locking/lockdep-design.txt
View File

@ -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:
----------------