The patch titled
lockdep: design docs
has been added to the -mm tree. Its filename is
lockdep-design-docs.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
------------------------------------------------------
Subject: lockdep: design docs
From: Ingo Molnar <mingo@xxxxxxx>
Lock validator design documentation.
Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
Signed-off-by: Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---
Documentation/lockdep-design.txt | 197 +++++++++++++++++++++++++++++
1 file changed, 197 insertions(+)
diff -puN /dev/null Documentation/lockdep-design.txt
--- /dev/null
+++ a/Documentation/lockdep-design.txt
@@ -0,0 +1,197 @@
+Runtime locking correctness validator
+=====================================
+
+started by Ingo Molnar <mingo@xxxxxxxxxx>
+additions by Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>
+
+Lock-class
+----------
+
+The basic object the validator operates upon is a 'class' of locks.
+
+A class of locks is a group of locks that are logically the same with
+respect to locking rules, even if the locks may have multiple (possibly
+tens of thousands of) instantiations. For example a lock in the inode
+struct is one class, while each inode has its own instantiation of that
+lock class.
+
+The validator tracks the 'state' of lock-classes, and it tracks
+dependencies between different lock-classes. The validator maintains a
+rolling proof that the state and the dependencies are correct.
+
+Unlike an lock instantiation, the lock-class itself never goes away: when
+a lock-class is used for the first time after bootup it gets registered,
+and all subsequent uses of that lock-class will be attached to this
+lock-class.
+
+State
+-----
+
+The validator tracks lock-class usage history into 5 separate state bits:
+
+- 'ever held in hardirq context' [ == hardirq-safe ]
+- 'ever held in softirq context' [ == softirq-safe ]
+- 'ever held with hardirqs enabled' [ == hardirq-unsafe ]
+- 'ever held with softirqs and hardirqs enabled' [ == softirq-unsafe ]
+
+- 'ever used' [ == !unused ]
+
+Single-lock state rules:
+------------------------
+
+A softirq-unsafe lock-class is automatically hardirq-unsafe as well. The
+following states are exclusive, and only one of them is allowed to be
+set for any lock-class:
+
+ <hardirq-safe> and <hardirq-unsafe>
+ <softirq-safe> and <softirq-unsafe>
+
+The validator detects and reports lock usage that violate these
+single-lock state rules.
+
+Multi-lock dependency rules:
+----------------------------
+
+The same lock-class must not be acquired twice, because this could lead
+to lock recursion deadlocks.
+
+Furthermore, two locks may not be taken in different order:
+
+ <L1> -> <L2>
+ <L2> -> <L1>
+
+because this could lead to lock inversion deadlocks. (The validator
+finds such dependencies in arbitrary complexity, i.e. there can be any
+other locking sequence between the acquire-lock operations, the
+validator will still track all dependencies between locks.)
+
+Furthermore, the following usage based lock dependencies are not allowed
+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
+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
+lock.
+
+The above rules are enforced for any locking sequence that occurs in the
+kernel: when acquiring a new lock, the validator checks whether there is
+any rule violation between the new lock and any of the held locks.
+
+When a lock-class changes its state, the following aspects of the above
+dependency rules are enforced:
+
+- if a new hardirq-safe lock is discovered, we check whether it
+ took any hardirq-unsafe lock in the past.
+
+- if a new softirq-safe lock is discovered, we check whether it took
+ any softirq-unsafe lock in the past.
+
+- if a new hardirq-unsafe lock is discovered, we check whether any
+ hardirq-safe lock took it in the past.
+
+- if a new softirq-unsafe lock is discovered, we check whether any
+ softirq-safe lock took it in the past.
+
+(Again, we do these checks too on the basis that an interrupt context
+could interrupt _any_ of the irq-unsafe or hardirq-unsafe locks, which
+could lead to a lock inversion deadlock - even if that lock scenario did
+not trigger in practice yet.)
+
+Exception: Nested data dependencies leading to nested locking
+-------------------------------------------------------------
+
+There are a few cases where the Linux kernel acquires more than one
+instance of the same lock-class. Such cases typically happen when there
+is some sort of hierarchy within objects of the same type. In these
+cases there is an inherent "natural" ordering between the two objects
+(defined by the properties of the hierarchy), and the kernel grabs the
+locks in this fixed order on each of the objects.
+
+An example of such an object hieararchy that results in "nested locking"
+is that of a "whole disk" block-dev object and a "partition" block-dev
+object; the partition is "part of" the whole device and as long as one
+always takes the whole disk lock as a higher lock than the partition
+lock, the lock ordering is fully correct. The validator does not
+automatically detect this natural ordering, as the locking rule behind
+the ordering is not static.
+
+In order to teach the validator about this correct usage model, new
+versions of the various locking primitives were added that allow you to
+specify a "nesting level". An example call, for the block device mutex,
+looks like this:
+
+enum bdev_bd_mutex_lock_class
+{
+ BD_MUTEX_NORMAL,
+ BD_MUTEX_WHOLE,
+ BD_MUTEX_PARTITION
+};
+
+ mutex_lock_nested(&bdev->bd_contains->bd_mutex, BD_MUTEX_PARTITION);
+
+In this case the locking is done on a bdev object that is known to be a
+partition.
+
+The validator treats a lock that is taken in such a nested fasion as a
+separate (sub)class for the purposes of validation.
+
+Note: When changing code to use the _nested() primitives, be careful and
+check really thoroughly that the hiearchy is correctly mapped; otherwise
+you can get false positives or false negatives.
+
+Proof of 100% correctness:
+--------------------------
+
+The validator achieves perfect, mathematical 'closure' (proof of locking
+correctness) in the sense that for every simple, standalone single-task
+locking sequence that occured at least once during the lifetime of the
+kernel, the validator proves it with a 100% certainty that no
+combination and timing of these locking sequences can cause any class of
+lock related deadlock. [*]
+
+I.e. complex multi-CPU and multi-task locking scenarios do not have to
+occur in practice to prove a deadlock: only the simple 'component'
+locking chains have to occur at least once (anytime, in any
+task/context) for the validator to be able to prove correctness. (For
+example, complex deadlocks that would normally need more than 3 CPUs and
+a very unlikely constellation of tasks, irq-contexts and timings to
+occur, can be detected on a plain, lightly loaded single-CPU system as
+well!)
+
+This radically decreases the complexity of locking related QA of the
+kernel: what has to be done during QA is to trigger as many "simple"
+single-task locking dependencies in the kernel as possible, at least
+once, to prove locking correctness - instead of having to trigger every
+possible combination of locking interaction between CPUs, combined with
+every possible hardirq and softirq nesting scenario (which is impossible
+to do in practice).
+
+[*] assuming that the validator itself is 100% correct, and no other
+ part of the system corrupts the state of the validator in any way.
+ We also assume that all NMI/SMM paths [which could interrupt
+ even hardirq-disabled codepaths] are correct and do not interfere
+ with the validator. We also assume that the 64-bit 'chain hash'
+ value is unique for every lock-chain in the system. Also, lock
+ recursion must not be higher than 20.
+
+Performance:
+------------
+
+The above rules require _massive_ amounts of runtime checking. If we did
+that for every lock taken and for every irqs-enable event, it would
+render the system practically unusably slow. The complexity of checking
+is O(N^2), so even with just a few hundred lock-classes we'd have to do
+tens of thousands of checks for every event.
+
+This problem is solved by checking any given 'locking scenario' (unique
+sequence of locks taken after each other) only once. A simple stack of
+held locks is maintained, and a lightweight 64-bit hash value is
+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.
_
Patches currently in -mm which might be from mingo@xxxxxxx are
origin.patch
define-__raw_get_cpu_var-and-use-it.patch
ide-cd-end-of-media-error-fix.patch
lock-validator-introduce-warn_on_oncecond.patch
emu10k1-mark-midi_spinlock-as-used.patch
epoll-use-unlocked-wqueue-operations.patch
pacct-none-delayed-process-accounting-accumulation.patch
disable-debugging-version-of-write_lock.patch
fix-drivers-mfd-ucb1x00-corec-irq-probing-bug.patch
cifs-remove-f_ownerlock-use.patch
lock-validator-fix-ns83820c-irq-flags-bug.patch
revert-gregkh-pci-pci-test-that-drivers-properly-call-pci_set_master.patch
x86-re-enable-generic-numa.patch
i386-fix-softirq-accounting-with-4k-stacks.patch
vdso-randomize-the-i386-vdso-by-moving-it-into-a-vma.patch
vdso-randomize-the-i386-vdso-by-moving-it-into-a-vma-tidy.patch
vdso-randomize-the-i386-vdso-by-moving-it-into-a-vma-arch_vma_name-fix.patch
vdso-randomize-the-i386-vdso-by-moving-it-into-a-vma-vs-x86_64-mm-reliable-stack-trace-support-i386.patch
vdso-randomize-the-i386-vdso-by-moving-it-into-a-vma-vs-x86_64-mm-reliable-stack-trace-support-i386-2.patch
vdso-randomize-the-i386-vdso-by-moving-it-into-a-vma-vs-x86_64-mm-reliable-stack-trace-support-i386-2-revert-maxmem-change.patch
work-around-ppc64-bootup-bug-by-making-mutex-debugging-save-restore-irqs.patch
kernel-kernel-cpuc-to-mutexes.patch
spin-rwlock-init-cleanups.patch
time-clocksource-infrastructure.patch
sched-fix-smt-nice-lock-contention-and-optimization.patch
sched-fix-smt-nice-lock-contention-and-optimization-tidy.patch
sched-comment-bitmap-size-accounting.patch
sched-fix-interactive-ceiling-code.patch
sched-cpu-hotplug-race-vs-set_cpus_allowed.patch
sched-implement-smpnice.patch
sched-protect-calculation-of-max_pull-from-integer-wrap.patch
sched-store-weighted-load-on-up.patch
sched-add-discrete-weighted-cpu-load-function.patch
sched-prevent-high-load-weight-tasks-suppressing-balancing.patch
sched-improve-stability-of-smpnice-load-balancing.patch
sched-improve-smpnice-load-balancing-when-load-per-task.patch
smpnice-dont-consider-sched-groups-which-are-lightly-loaded-for-balancing.patch
smpnice-dont-consider-sched-groups-which-are-lightly-loaded-for-balancing-fix.patch
sched-modify-move_tasks-to-improve-load-balancing-outcomes.patch
sched-avoid-unnecessarily-moving-highest-priority-task-move_tasks.patch
sched-avoid-unnecessarily-moving-highest-priority-task-move_tasks-fix-2.patch
sched_domain-handle-kmalloc-failure.patch
sched_domain-handle-kmalloc-failure-fix.patch
sched_domain-dont-use-gfp_atomic.patch
sched_domain-use-kmalloc_node.patch
sched_domain-allocate-sched_group-structures-dynamically.patch
sched-mc-smt-power-savings-sched-policy.patch
sched-uninline-task_rq_lock.patch
bug-if-setscheduler-is-called-from-interrupt-context.patch
sched-add-above-background-load-function.patch
mm-implement-swap-prefetching.patch
pi-futex-futex-code-cleanups.patch
pi-futex-robust-futex-docs-fix.patch
pi-futex-introduce-debug_check_no_locks_freed.patch
pi-futex-introduce-warn_on_smp.patch
pi-futex-add-plist-implementation.patch
pi-futex-scheduler-support-for-pi.patch
pi-futex-rt-mutex-core.patch
pi-futex-rt-mutex-docs.patch
pi-futex-rt-mutex-docs-update.patch
pi-futex-rt-mutex-debug.patch
pi-futex-rt-mutex-tester.patch
pi-futex-rt-mutex-tester-fix.patch
pi-futex-rt-mutex-futex-api.patch
pi-futex-futex_lock_pi-futex_unlock_pi-support.patch
pi-futex-futex_lock_pi-futex_unlock_pi-support-fix.patch
fix-rt-mutex-defaults-and-dependencies.patch
drop-tasklist-lock-in-do_sched_setscheduler.patch
rtmutex-modify-rtmutex-tester-to-test-the-setscheduler.patch
rtmutex-propagate-priority-settings-into-pi-lock-chains.patch
rtmutex-propagate-priority-settings-into-pi-lock-chains-fix.patch
futex_requeue-optimization.patch
fix-ide-deadlock-in-error-reporting-code.patch
genirq-rename-desc-handler-to-desc-chip.patch
genirq-rename-desc-handler-to-desc-chip-power-fix.patch
genirq-rename-desc-handler-to-desc-chip-ia64-fix.patch
genirq-rename-desc-handler-to-desc-chip-ia64-fix-2.patch
genirq-rename-desc-handler-to-desc-chip-terminate_irqs-fix.patch
genirq-sem2mutex-probe_sem-probing_active.patch
genirq-cleanup-merge-irq_affinity-into-irq_desc.patch
genirq-cleanup-remove-irq_descp.patch
genirq-cleanup-remove-irq_descp-fix.patch
genirq-cleanup-remove-fastcall.patch
genirq-cleanup-misc-code-cleanups.patch
genirq-cleanup-reduce-irq_desc_t-use-mark-it-obsolete.patch
genirq-cleanup-include-linux-irqh.patch
genirq-cleanup-merge-irq_dir-smp_affinity_entry-into-irq_desc.patch
genirq-cleanup-merge-pending_irq_cpumask-into-irq_desc.patch
genirq-cleanup-turn-arch_has_irq_per_cpu-into-config_irq_per_cpu.patch
genirq-debug-better-debug-printout-in-enable_irq.patch
genirq-add-retrigger-irq-op-to-consolidate-hw_irq_resend.patch
genirq-doc-comment-include-linux-irqh-structures.patch
genirq-doc-handle_irq_event-and-__do_irq-comments.patch
genirq-cleanup-no_irq_type-cleanups.patch
genirq-doc-add-design-documentation.patch
genirq-add-genirq-sw-irq-retrigger.patch
genirq-add-irq_noprobe-support.patch
genirq-add-irq_norequest-support.patch
genirq-add-irq_noautoen-support.patch
genirq-update-copyrights.patch
genirq-core.patch
genirq-msi-fixes-2.patch
genirq-add-irq-chip-support.patch
genirq-add-irq-chip-support-fix.patch
genirq-add-irq-chip-support-misroute-irq-dont-call-desc-chip-end.patch
genirq-add-handle_bad_irq.patch
genirq-add-irq-wake-power-management-support.patch
genirq-add-sa_trigger-support.patch
genirq-cleanup-no_irq_type-no_irq_chip-rename.patch
genirq-more-verbose-debugging-on-unexpected-irq-vectors.patch
genirq-ia64-build-fix.patch
genirq-add-irq_type_sense_mask.patch
genirq-add-irq-chip-support-fasteoi-handler-handle-interrupt-disabling.patch
genirq-irq-document-what-an-irq-is.patch
genirq-add-chip-eoi-fastack-fasteoi-core.patch
genirq-add-chip-eoi-fastack-fasteoi-fix.patch
lockdep-floppyc-irq-release-fix.patch
lockdep-acpi-locking-fix.patch
lockdep-console_init-after-local_irq_enable.patch
lockdep-add-is_module_address.patch
lockdep-add-print_ip_sym.patch
lockdep-add-per_cpu_offset.patch
lockdep-add-disable-enable_irq_lockdep-api.patch
lockdep-add-local_irq_enable_in_hardirq-api.patch
lockdep-add-declare_completion_onstack-api.patch
lockdep-clean-up-rwsems.patch
lockdep-rename-debug_warn_on.patch
lockdep-remove-debug_bug_on.patch
lockdep-remove-mutex-deadlock-checking-code.patch
lockdep-better-lock-debugging.patch
lockdep-mutex-section-binutils-workaround.patch
lockdep-locking-init-debugging-improvement.patch
lockdep-beautify-x86_64-stacktraces.patch
lockdep-x86_64-document-stack-frame-internals.patch
lockdep-i386-remove-multi-entry-backtraces.patch
lockdep-stacktrace-subsystem-core.patch
lockdep-s390-config_frame_pointer-support.patch
lockdep-stacktrace-subsystem-i386-support.patch
lockdep-stacktrace-subsystem-x86_64-support.patch
lockdep-stacktrace-subsystem-s390-support.patch
lockdep-irqtrace-subsystem-core.patch
lockdep-irqtrace-subsystem-docs.patch
lockdep-irqtrace-subsystem-i386-support.patch
lockdep-irqtrace-subsystem-x86_64-support.patch
lockdep-irqtrace-subsystem-s390-support.patch
lockdep-locking-api-self-tests.patch
lockdep-irqtrace-cleanup-of-include-asm-i386-irqflagsh.patch
lockdep-irqtrace-cleanup-of-include-asm-x86_64-irqflagsh.patch
lockdep-core.patch
lockdep-design-docs.patch
lockdep-procfs.patch
lockdep-prove-rwsem-locking-correctness.patch
lockdep-prove-spinlock-rwlock-locking-correctness.patch
lockdep-prove-mutex-locking-correctness.patch
lockdep-kconfig.patch
lockdep-print-all-lock-classes-on-sysrq-d.patch
lockdep-x86_64-early-init.patch
lockdep-x86-smp-alternatives-workaround.patch
lockdep-do-not-recurse-in-printk.patch
lockdep-fix-rt_hash_lock_sz.patch
lockdep-s390-turn-validator-off-in-machine-check-handler.patch
lockdep-enable-on-i386.patch
lockdep-enable-on-x86_64.patch
lockdep-enable-on-s390.patch
lockdep-annotate-direct-io.patch
lockdep-annotate-serial.patch
lockdep-annotate-dcache.patch
lockdep-annotate-i_mutex.patch
lockdep-annotate-futex.patch
lockdep-annotate-genirq.patch
lockdep-annotate-waitqueues.patch
lockdep-annotate-mm.patch
lockdep-annotate-serio.patch
lockdep-annotate-skb_queue_head_init.patch
lockdep-annotate-timer-base-locks.patch
lockdep-annotate-scheduler-runqueue-locks.patch
lockdep-annotate-hrtimer-base-locks.patch
lockdep-annotate-sock_lock_init.patch
lockdep-annotate-af_unix-locking.patch
lockdep-annotate-bh_lock_sock.patch
lockdep-annotate-ieee1394-skb-queue-head-locking.patch
lockdep-annotate-mmap_sem.patch
lockdep-annotate-sunrpc-code.patch
lockdep-annotate-ntfs-locking-rules.patch
lockdep-annotate-the-quota-code.patch
lockdep-annotate-usbfs.patch
lockdep-annotate-sound-core-seq-seq_portsc.patch
lockdep-annotate-sound-core-seq-seq_devicec.patch
lockdep-annotate-8390c-disable_irq.patch
lockdep-annotate-3c59xc-disable_irq.patch
lockdep-annotate-forcedethc-disable_irq.patch
lockdep-annotate-enable_in_hardirq.patch
lockdep-annotate-on-stack-completions.patch
lockdep-annotate-qeth-driver.patch
lockdep-annotate-s_lock.patch
lockdep-annotate-sb-s_umount.patch
lockdep-annotate-slab-code.patch
lockdep-annotate-blkdev-nesting.patch
acpi-reduce-code-size-clean-up-fix-validator-message.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
