Messages in this thread | | | From | Waiman Long <> | Subject | Re: [RFC PATCH] spinlock_debug: Save stacktrace at lock acquisition | Date | Tue, 29 Jun 2021 22:01:01 -0400 |
| |
On 6/29/21 9:28 PM, Guru Das Srinagesh wrote: > In case of spinlock recursion bugs, knowing which entity acquired the > lock initially is key to debugging. Therefore, save the stack frames > when the lock is acquired and print them when spinlock recursion is > detected. > > Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org> > --- > include/linux/spinlock_types.h | 3 +++ > kernel/locking/spinlock_debug.c | 9 +++++++++ > 2 files changed, 12 insertions(+) > > diff --git a/include/linux/spinlock_types.h b/include/linux/spinlock_types.h > index b981caa..8a68d55 100644 > --- a/include/linux/spinlock_types.h > +++ b/include/linux/spinlock_types.h > @@ -22,6 +22,9 @@ typedef struct raw_spinlock { > #ifdef CONFIG_DEBUG_SPINLOCK > unsigned int magic, owner_cpu; > void *owner; > +#define MAX_STACK_LEN 16 > + int stack_len; > + unsigned long stack_trace[MAX_STACK_LEN]; > #endif
Nak
Locking problem like this should be detected by the lockdep code. Adding 136 bytes (64-bit archs) to the size of a spinlock is just too big an overhead.
Regards, Longman
| |