Re: [PATCH 2/2] spinlock_debug: Print kallsyms name for lock

[Stephen Boyd]

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/