[lkml]   [2012]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] spinlock_debug: Print kallsyms name for lock
On 04/23/12 14:54, Andrew Morton wrote:
>> --- a/lib/spinlock_debug.c
>> +++ b/lib/spinlock_debug.c
>> @@ -58,7 +58,7 @@ static void spin_dump(raw_spinlock_t *lock, const char *msg)
>> printk(KERN_EMERG "BUG: spinlock %s on CPU#%d, %s/%d\n",
>> msg, raw_smp_processor_id(),
>> current->comm, task_pid_nr(current));
>> - printk(KERN_EMERG " lock: %p, .magic: %08x, .owner: %s/%d, "
>> + printk(KERN_EMERG " lock: %ps, .magic: %08x, .owner: %s/%d, "
>> ".owner_cpu: %d\n",
>> lock, lock->magic,
>> owner ? owner->comm : "<none>",
> Maybe. It will only do useful things for statically-allocated locks
> which are rare and which we are unlikely to screw up as easily as locks
> which lie in dynamically allocated memory.

Agreed. It catches the really stupid stuff and that's about it. I was
thinking we could get more information about dynamic allocated locks by
adding some code to slab to find the slab that a pointer is allocated
in. Does that sound possible?

With stacktrace support in slub we could even find the caller who
allocated the storage for the spinlock. It might be useful but one could
argue the stacktrace from this function is already pretty useful for
tracking down which spinlock it is.

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

 \ /
  Last update: 2012-04-24 05:19    [W:0.059 / U:3.176 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site