linux-kernel - Re: [RFC 11/12] Drivers: hv: vmbus: Wait for MODIFYCHANNEL to finish when offlining CPUs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 24 Jun 2024 10:55:18 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: mhklinux@...look.com
Cc: kys@...rosoft.com, haiyangz@...rosoft.com, wei.liu@...nel.org,
	decui@...rosoft.com, tglx@...utronix.de, mingo@...hat.com,
	bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org,
	hpa@...or.com, lpieralisi@...nel.org, kw@...ux.com, robh@...nel.org,
	bhelgaas@...gle.com, James.Bottomley@...senpartnership.com,
	martin.petersen@...cle.com, arnd@...db.de,
	linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org, linux-scsi@...r.kernel.org,
	linux-arch@...r.kernel.org, maz@...nel.org, den@...inux.co.jp,
	jgowans@...zon.com, dawei.li@...ngroup.cn
Subject: Re: [RFC 11/12] Drivers: hv: vmbus: Wait for MODIFYCHANNEL to finish
 when offlining CPUs

Hi Michael,

On Mon, Jun 03, 2024 at 10:09:39PM -0700, mhkelley58@...il.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
>