forked from luck/tmp_suning_uos_patched
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>
This commit is contained in:
parent
c003ed9289
commit
1d4093d3b3
|
@ -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:
|
||||
----------------
|
||||
|
|
Loading…
Reference in New Issue
Block a user