Hi Michael,
On Mon, Jun 03, 2024 at 10:09:39PM -0700, mhkelle...@gmail.com wrote:
[...]
> diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> index bf35bb40c55e..571b2955b38e 100644
> --- a/drivers/hv/hyperv_vmbus.h
> +++ b/drivers/hv/hyperv_vmbus.h
> @@ -264,6 +264,14 @@ struct vmbus_connection {
> struct irq_domain *vmbus_irq_domain;
> struct irq_chip vmbus_irq_chip;
>
> + /*
> + * VM-wide counts of MODIFYCHANNEL messages sent and completed.
> + * Used when taking a CPU offline to make sure the relevant
> + * MODIFYCHANNEL messages have been completed.
> + */
> + u64 modchan_sent;
> + u64 modchan_completed;
> +
Looks to me, we can just use atomic64_t here: modifying channels is far
from hotpath, so the cost of atomic increment is not a big issue, and we
avoid possible data races now and in the future.
Thoughts?
Regards,
Boqun
> /*
> * An offer message is handled first on the work_queue, and then
> * is further handled on handle_primary_chan_wq or
> --
> 2.25.1
>
