[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