Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios

[Vitaly Kuznetsov]

KY Srinivasan <kys@xxxxxxxxxxxxx> writes:

>> -----Original Message-----
>> From: Vitaly Kuznetsov [mailto:vkuznets@xxxxxxxxxx]
>> Sent: Monday, March 21, 2016 12:52 AM
>> To: KY Srinivasan <kys@xxxxxxxxxxxxx>
>> Cc: devel@xxxxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Haiyang
>> Zhang <haiyangz@xxxxxxxxxxxxx>; Alex Ng (LIS) <alexng@xxxxxxxxxxxxx>;
>> Radim Krcmar <rkrcmar@xxxxxxxxxx>; Cathy Avery <cavery@xxxxxxxxxx>
>> Subject: Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
>> 
>> KY Srinivasan <kys@xxxxxxxxxxxxx> writes:
>> 
>> >> -----Original Message-----
>> >> From: Vitaly Kuznetsov [mailto:vkuznets@xxxxxxxxxx]
>> >> Sent: Friday, March 18, 2016 5:33 AM
>> >> To: devel@xxxxxxxxxxxxxxxxxxxxxx
>> >> Cc: linux-kernel@xxxxxxxxxxxxxxx; KY Srinivasan <kys@xxxxxxxxxxxxx>;
>> >> Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>; Alex Ng (LIS)
>> >> <alexng@xxxxxxxxxxxxx>; Radim Krcmar <rkrcmar@xxxxxxxxxx>; Cathy
>> >> Avery <cavery@xxxxxxxxxx>
>> >> Subject: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
>> >>
>> >> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is
>> always
>> >> delivered to CPU0 regardless of what CPU we're sending
>> >> CHANNELMSG_UNLOAD
>> >> from. vmbus_wait_for_unload() doesn't account for the fact that in case
>> >> we're crashing on some other CPU and CPU0 is still alive and operational
>> >> CHANNELMSG_UNLOAD_RESPONSE will be delivered there completing
>> >> vmbus_connection.unload_event, our wait on the current CPU will never
>> >> end.
>> >
>> > What was the host you were testing on?
>> >
>> 
>> I was testing on both 2012R2 and 2016TP4. The bug is easily reproducible
>> by forcing crash on a secondary CPU, e.g.:
>
> Prior to 2012R2, all messages would be delivered on CPU0 and this includes CHANNELMSG_UNLOAD_RESPONSE.
> For this reason we don't support kexec on pre-2012 R2 hosts. On 2012. From 2012 R2 on, all vmbus 
> messages (responses) will be delivered on  the CPU that we initially set up - look at the code in
> vmbus_negotiate_version().

Ok, missed that. In that case we need to remember which CPU it was --
I'll add this in v2.

> So on post 2012 R2 hosts, the response to CHANNELMSG_UNLOAD_RESPONSE
> will be delivered on the CPU where we initiate the contact with the host - CHANNELMSG_INITIATE_CONTACT message.
> So, maybe we can stash away the CPU on which we made the initial contact and poll the state on that CPU
> to make forward progress in the case of crash.

Yes, we can't have any expectation about other CPUs on crash as they can
be in any state (crashing also, hanging on some mutex/spinlock/...,) so
we need to use current CPU only. I'll fix and resend.

Thanks!

-- 
  Vitaly