Waiman Long ecd384c436 locking/lockdep: Iterate lock_classes directly when reading lockdep files ... [ Upstream commit fb7275acd6fb988313dddd8d3d19efa70d9015ad ] When dumping lock_classes information via /proc/lockdep, we can't take the lockdep lock as the lock hold time is indeterminate. Iterating over all_lock_classes without holding lock can be dangerous as there is a slight chance that it may branch off to other lists leading to infinite loop or even access invalid memory if changes are made to all_lock_classes list in parallel. To avoid this problem, iteration of lock classes is now done directly on the lock_classes array itself. The lock_classes_in_use bitmap is checked to see if the lock class is being used. To avoid iterating the full array all the times, a new max_lock_class_idx value is added to track the maximum lock_class index that is currently being used. We can theoretically take the lockdep lock for iterating all_lock_classes when other lockdep files (lockdep_stats and lock_stat) are accessed as the lock hold time will be shorter for them. For consistency, they are also modified to iterate the lock_classes array directly. Signed-off-by: Waiman Long <longman@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20220211035526.1329503-2-longman@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>		2022-04-08 14:40:32 +02:00
..
lock_events_list.h
lock_events.c
lock_events.h
lockdep_internals.h
lockdep_proc.c
lockdep_states.h
lockdep.c
locktorture.c
Makefile
mcs_spinlock.h
mutex-debug.c
mutex-debug.h
mutex.c
mutex.h
osq_lock.c
percpu-rwsem.c
qrwlock.c
qspinlock_paravirt.h
qspinlock_stat.h
qspinlock.c
rtmutex_common.h
rtmutex-debug.c
rtmutex-debug.h
rtmutex.c
rtmutex.h
rwsem.c
rwsem.h
semaphore.c
spinlock_debug.c
spinlock.c
test-ww_mutex.c