[Skiboot] [PATCH 2/2] hw/bt: Update the BT state after completion

[Neelesh Gupta]

On 06/26/2015 11:40 AM, Alistair Popple wrote:
> Hi Neelesh,
>
> I can't quite see the race here? The list (and the bt state) should only be
> updated with the lock held. Once we have read a response the bt device is idle
> and ready to send another message. It shouldn't matter if something gets added
> to the list as it will just be picked up for sending by the bt_poll()
> function.

So, this patch depends upon [PATCH 1/2] of this series. If we set the 
state to IDLE
before ipmi_cmd_done() .. the current outstanding message is still there 
in the
queue and chances are to be picked up again by the bt_poll()..

Neelesh.

>
> Regards,
>
> Alistair
>
> On Wed, 24 Jun 2015 22:40:59 Neelesh Gupta wrote:
>> It is racy to update the BT state before dequeuing the message
>> through ipmi_cmd_done() as there is chance of new message to
>> fiddle the list.
>>
>> Signed-off-by: Neelesh Gupta <neelegup at linux.vnet.ibm.com>
>> ---
>>   hw/bt.c |    4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/bt.c b/hw/bt.c
>> index 9aa86b9..5b523d3 100644
>> --- a/hw/bt.c
>> +++ b/hw/bt.c
>> @@ -262,8 +262,6 @@ static void bt_get_resp(void)
>>   		ipmi_msg->data[i] = bt_inb(BT_HOST2BMC);
>>   	bt_set_h_busy(false);
>>   
>> -	bt_set_state(BT_STATE_IDLE);
>> -
>>   	unlock(&bt.lock);
>>   
>>   	/*
>> @@ -276,6 +274,8 @@ static void bt_get_resp(void)
>>   	ipmi_cmd_done(cmd, netfn, cc, ipmi_msg);
>>   	lock(&bt.lock);
>>   
>> +	bt_set_state(BT_STATE_IDLE);
>> +
>>   	return;
>>   }
>>   
>>
>> _______________________________________________
>> Skiboot mailing list
>> Skiboot at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/skiboot
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/skiboot/attachments/20150626/07d24c67/attachment.html>