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

[KY Srinivasan]

> -----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(). 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.

Regards,

K. Y