RE: [PATCH] Drivers: hv: vmbus: fix init_vp_index() for reloading hv_netvsc

[Dexuan Cui]

> From: devel [mailto:driverdev-devel-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf
> Of Dexuan Cui
> Sent: Wednesday, August 12, 2015 21:49
> To: gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; driverdev-
> devel@xxxxxxxxxxxxxxxxxxxxxx; olaf@xxxxxxxxx; apw@xxxxxxxxxxxxx;
> jasowang@xxxxxxxxxx; KY Srinivasan <kys@xxxxxxxxxxxxx>
> Subject: [PATCH] Drivers: hv: vmbus: fix init_vp_index() for reloading hv_netvsc
> 
> This fixes the recent commit:
> Drivers: hv: vmbus: Further improve CPU affiliation logic
> 
> Without the fix, reloading hv_netvsc hangs the guest.
> 
> Signed-off-by: Dexuan Cui <decui@xxxxxxxxxxxxx>
> ---
>  drivers/hv/channel_mgmt.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> index 2f9aead..f61bd07 100644
> --- a/drivers/hv/channel_mgmt.c
> +++ b/drivers/hv/channel_mgmt.c
> @@ -458,6 +458,19 @@ static void init_vp_index(struct vmbus_channel
> *channel, const uuid_le *type_gui
>  			continue;
>  		}
> 
> +		if (cpumask_weight(&primary->alloced_cpus_in_node) ==
> +		    cpumask_weight(cpumask_of_node(primary->numa_node))) {
> +			/*
> +			 * We have cycled through all the CPUs in the node;
> +			 * reset the alloced map.
> +			 * This is necessary because we never clear
> +			 * primary->alloced_cpus_in_node in other places.
> +			 * We need this to "break" the loop when reloading
> +			 * hv_netvsc in SMP guest.
> +			 */
> +			cpumask_clear(&primary->alloced_cpus_in_node);
> +		}
> +
>  		if (!cpumask_test_cpu(cur_cpu,
>  				&primary->alloced_cpus_in_node)) {
>  			cpumask_set_cpu(cur_cpu,
> --

Sorry, please drop the patch.

I shouldn't simply clear primary->alloced_cpus_in_node -- I didn't realize
reloading hv_netvsc doesn't invoke init_vp_index() for the primary channel.

I'll make a V2 patch.

Thanks,
-- Dexuan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/