[Skiboot] [PATCH] core/lock: Stop drop_my_locks() from always causing abort

Stewart Smith stewart at linux.ibm.com
Tue Feb 5 16:29:51 AEDT 2019


Vasant Hegde <hegdevasant at linux.vnet.ibm.com> writes:
> On 01/19/2019 01:31 AM, Reza Arbab wrote:
>> The loop in drop_my_locks() looks like this:
>> 
>> 	while((l = list_pop(&this_cpu()->locks_held, struct lock, list)) != NULL) {
>> 		if (warn)
>> 			prlog(PR_ERR, "  %s\n", l->owner);
>> 		unlock(l);
>> 	}
>> 
>> Both list_pop() and unlock() call list_del(). This means that on the
>> last iteration of the loop, the list will be empty when we get to
>> unlock_check(), causing this:
>> 
>>    LOCK ERROR: Releasing lock we don't hold depth @0x30493d20 (state: 0x0000000000000001)
>>    [13836.000173140,0] Aborting!
>>    CPU 0000 Backtrace:
>>     S: 0000000031c03930 R: 000000003001d840   ._abort+0x60
>>     S: 0000000031c039c0 R: 000000003001a0c4   .lock_error+0x64
>>     S: 0000000031c03a50 R: 0000000030019c70   .unlock+0x54
>>     S: 0000000031c03af0 R: 000000003001a040   .drop_my_locks+0xf4
>> 
>> To fix this, change list_pop() to list_top().
>> 
>> Signed-off-by: Reza Arbab <arbab at linux.ibm.com>
>
> Reviewed-by: Vasant Hegde <hegdevasant at linux.vnet.ibm.com>
>
>
> @Stewart,
>    I think we should pick this for Stable branch. #6.0+

Ack. Merged to master as of 9ef153f6f013b224db8e9b78764ef6cf89c152fa and
cherry picking back into stable

-- 
Stewart Smith
OPAL Architect, IBM.



More information about the Skiboot mailing list