lockdep: Fix the module unload key range freeing logic
authorPeter Zijlstra <peterz@infradead.org>
Thu, 26 Feb 2015 15:23:11 +0000 (16:23 +0100)
committerIngo Molnar <mingo@kernel.org>
Mon, 23 Mar 2015 09:49:07 +0000 (10:49 +0100)
commit35a9393c95b31870a74f51a3e7455f33f5657b6f
tree9a0e913b3d2dc02956c03a24b535a3604bb2dfa7
parentbc465aa9d045feb0e13b4a8f32cc33c1943f62d6
lockdep: Fix the module unload key range freeing logic

Module unload calls lockdep_free_key_range(), which removes entries
from the data structures. Most of the lockdep code OTOH assumes the
data structures are append only; in specific see the comments in
add_lock_to_list() and look_up_lock_class().

Clearly this has only worked by accident; make it work proper. The
actual scenario to make it go boom would involve the memory freed by
the module unlock being re-allocated and re-used for a lock inside of
a rcu-sched grace period. This is a very unlikely scenario, still
better plug the hole.

Use RCU list iteration in all places and ammend the comments.

Change lockdep_free_key_range() to issue a sync_sched() between
removal from the lists and returning -- which results in the memory
being freed. Further ensure the callers are placed correctly and
comment the requirements.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrey Tsyvarev <tsyvarev@ispras.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
kernel/locking/lockdep.c
kernel/module.c