linux/kernel/lockdep.c, branch v2.6.24

lockdep: fix kernel crash on module unload

2008-01-24T16:01:09Z

Michael Wu noticed in his lkml post at http://marc.info/?l=linux-kernel&m=119396182726091&w=2 that certain wireless drivers ended up having their name in module memory, which would then crash the kernel on module unload. The patch he proposed was a bit clumsy in that it increased the size of a lockdep entry significantly; the patch below tries another approach, it checks, on module teardown, if the name of a class is in module space and then zaps the class. This is very similar to what we already do with keys that are in module space. Signed-off-by: Arjan van de Ven Signed-off-by: Ingo Molnar Acked-by: Peter Zijlstra Signed-off-by: Linus Torvalds

lockdep: fix internal double unlock during self-test

2008-01-16T08:51:58Z

Lockdep, during self-test (when it was simulating double unlocks) was sometimes unconditionally unlocking a spinlock when it had not been locked. This won't work for ticket locks. Signed-off-by: Nick Piggin Signed-off-by: Ingo Molnar Signed-off-by: Peter Zijlstra

lockdep: make cli/sti annotation warnings clearer

2007-12-07T18:02:47Z

make cli/sti annotation warnings easier to interpret. Signed-off-by: Ingo Molnar Signed-off-by: Peter Zijlstra

lockdep: in_range() fix

2007-12-05T14:46:09Z

Torsten Kaiser wrote: | static inline int in_range(const void *start, const void *addr, const void *end) | { | return addr >= start && addr <= end; | } | This will return true, if addr is in the range of start (including) | to end (including). | | But debug_check_no_locks_freed() seems does: | const void *mem_to = mem_from + mem_len | -> mem_to is the last byte of the freed range, that fits in_range | lock_from = (void *)hlock->instance; | -> first byte of the lock | lock_to = (void *)(hlock->instance + 1); | -> first byte of the next lock, not last byte of the lock that is being checked! | | The test is: | if (!in_range(mem_from, lock_from, mem_to) && | !in_range(mem_from, lock_to, mem_to)) | continue; | So it tests, if the first byte of the lock is in the range that is freed ->OK | And if the first byte of the *next* lock is in the range that is freed | -> Not OK. We can also simplify in_range checks, we need only 2 comparisons, not 4. If the lock is not in memory range, it should be either at the left of range or at the right. Signed-off-by: Oleg Nesterov Signed-off-by: Ingo Molnar Signed-off-by: Peter Zijlstra

lockdep: fix debug_show_all_locks()

2007-12-05T14:46:09Z

fix the oops that can be seen in: http://bugzilla.kernel.org/attachment.cgi?id=13828&action=view it is not safe to print the locks of running tasks. (even with this fix we have a small race - but this is a debug function after all.) Signed-off-by: Ingo Molnar Signed-off-by: Peter Zijlstra

lockdep: fix a typo in the __lock_acquire comment

2007-10-28T19:47:01Z

Fix a typo in the __lock_acquire comment. Signed-off-by: Gautham R Shenoy Signed-off-by: Peter Zijlstra Signed-off-by: Ingo Molnar

Use helpers to obtain task pid in printks

2007-10-19T18:53:43Z

The task_struct->pid member is going to be deprecated, so start using the helpers (task_pid_nr/task_pid_vnr/task_pid_nr_ns) in the kernel. The first thing to start with is the pid, printed to dmesg - in this case we may safely use task_pid_nr(). Besides, printks produce more (much more) than a half of all the explicit pid usage. [akpm@linux-foundation.org: git-drm went and changed lots of stuff] Signed-off-by: Pavel Emelyanov Cc: Dave Airlie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

workqueue: debug flushing deadlocks with lockdep

2007-10-19T18:53:38Z

In the following scenario: code path 1: my_function() -> lock(L1); ...; flush_workqueue(); ... code path 2: run_workqueue() -> my_work() -> ...; lock(L1); ... you can get a deadlock when my_work() is queued or running but my_function() has acquired L1 already. This patch adds a pseudo-lock to each workqueue to make lockdep warn about this scenario. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Johannes Berg Acked-by: Oleg Nesterov Acked-by: Ingo Molnar Acked-by: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

lockdep: syscall exit check

2007-10-11T20:11:12Z

Provide a check to validate that we do not hold any locks when switching back to user-space. Signed-off-by: Peter Zijlstra Signed-off-by: Ingo Molnar

lockdep: fix mismatched lockdep_depth/curr_chain_hash

2007-10-11T20:11:11Z

It is possible for the current->curr_chain_key to become inconsistent with the current index if the chain fails to validate. The end result is that future lock_acquire() operations may inadvertently fail to find a hit in the cache resulting in a new node being added to the graph for every acquire. Signed-off-by: Gregory Haskins Signed-off-by: Peter Zijlstra Signed-off-by: Ingo Molnar