From: Hamza Mahfooz <hamzamahf...@linux.microsoft.com> Sent: Thursday, January
16, 2025 3:07 PM
>
> The core functionality in target_cpu_store() is also needed in a
> subsequent patch for automatically changing the CPU when taking
> a CPU offline. As such, factor out the body of target_cpu_store()
> into new function vmbus_channel_set_cpu() that can also be used
> elsewhere.
>
> No functional change is intended.
>
> Cc: Boqun Feng <boqun.f...@gmail.com>
> Cc: Michael Kelley <mhkli...@outlook.com>
> Cc: Wei Liu <wei....@kernel.org>
> Signed-off-by: Hamza Mahfooz <hamzamahf...@linux.microsoft.com>
> ---
> v2: separate vmbus_channel_set_cpu() changes from
> cpu offlining changes.
>
> v3: address comments from Michael.
> ---
> drivers/hv/vmbus_drv.c | 50 +++++++++++++++++++++++++-----------------
> include/linux/hyperv.h | 1 +
> 2 files changed, 31 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 2892b8da20a5..0ca0e85e6edd 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -1611,16 +1611,16 @@ static ssize_t target_cpu_show(struct vmbus_channel
> *channel, char *buf)
> {
> return sprintf(buf, "%u\n", channel->target_cpu);
> }
> -static ssize_t target_cpu_store(struct vmbus_channel *channel,
> - const char *buf, size_t count)
> +
> +int vmbus_channel_set_cpu(struct vmbus_channel *channel, u32 target_cpu)
> {
> - u32 target_cpu, origin_cpu;
> - ssize_t ret = count;
> + u32 origin_cpu;
> + int ret = 0;
>
> - if (vmbus_proto_version < VERSION_WIN10_V4_1)
> - return -EIO;
> + lockdep_assert_cpus_held();
With the previous bugs fixed, I applied both patches in this series
and did a test build. Unfortunately, lockdep_assert_cpus_held() is
not exported, and the build fails if CONFIG_HYPERV=m.
cpus_read_lock(), cpus_read_unlock(), and cpus_read_trylock() are
exported, but lockdep_assert_cpus_held() is not. I don't know why
they are inconsistent in that regard. You'll need to drop the use of
lockdep_assert_cpus_held() here and in hv_pick_new_cpu(), or
add a patch to export lockdep_assert_cpus_held(), assuming it's
valid to do so.
With any Hyper-V related changes, it's necessary to build and
test with CONFIG_HYPERV=m to catch problems like this.
> + lockdep_assert_held(&vmbus_connection.channel_mutex);
>
> - if (sscanf(buf, "%uu", &target_cpu) != 1)
> + if (vmbus_proto_version < VERSION_WIN10_V4_1)
> return -EIO;
>
> /* Validate target_cpu for the cpumask_test_cpu() operation below. */
> @@ -1630,22 +1630,17 @@ static ssize_t target_cpu_store(struct vmbus_channel
> *channel,
> if (!cpumask_test_cpu(target_cpu,
> housekeeping_cpumask(HK_TYPE_MANAGED_IRQ)))
> return -EINVAL;
>
> - /* No CPUs should come up or down during this. */
> - cpus_read_lock();
> -
> - if (!cpu_online(target_cpu)) {
> - cpus_read_unlock();
> + if (!cpu_online(target_cpu))
> return -EINVAL;
> - }
>
> /*
> - * Synchronizes target_cpu_store() and channel closure:
> + * Synchronizes vmbus_channel_set_cpu() and channel closure:
> *
> * { Initially: state = CHANNEL_OPENED }
> *
> * CPU1 CPU2
> *
> - * [target_cpu_store()] [vmbus_disconnect_ring()]
> + * [vmbus_channel_set_cpu()] [vmbus_disconnect_ring()]
> *
> * LOCK channel_mutex LOCK channel_mutex
> * LOAD r1 = state LOAD r2 = state
> @@ -1660,7 +1655,6 @@ static ssize_t target_cpu_store(struct vmbus_channel
> *channel,
> * Note. The host processes the channel messages "sequentially", in
> * the order in which they are received on a per-partition basis.
> */
> - mutex_lock(&vmbus_connection.channel_mutex);
>
> /*
> * Hyper-V will ignore MODIFYCHANNEL messages for "non-open" channels;
> @@ -1668,17 +1662,17 @@ static ssize_t target_cpu_store(struct vmbus_channel
> *channel,
> */
> if (channel->state != CHANNEL_OPENED_STATE) {
> ret = -EIO;
> - goto cpu_store_unlock;
> + goto end;
> }
>
> origin_cpu = channel->target_cpu;
> if (target_cpu == origin_cpu)
> - goto cpu_store_unlock;
> + goto end;
>
> if (vmbus_send_modifychannel(channel,
> hv_cpu_number_to_vp_number(target_cpu))) {
> ret = -EIO;
> - goto cpu_store_unlock;
> + goto end;
> }
>
> /*
> @@ -1708,9 +1702,25 @@ static ssize_t target_cpu_store(struct vmbus_channel
> *channel,
> origin_cpu, target_cpu);
> }
>
> -cpu_store_unlock:
> +end:
> + return ret;
> +}
> +
> +static ssize_t target_cpu_store(struct vmbus_channel *channel,
> + const char *buf, size_t count)
> +{
> + ssize_t ret = count;
> + u32 target_cpu;
> +
> + if (sscanf(buf, "%uu", &target_cpu) != 1)
> + return -EIO;
> +
> + cpus_read_lock();
> + mutex_lock(&vmbus_connection.channel_mutex);
> + ret = vmbus_channel_set_cpu(channel, target_cpu);
There's a problem here that I didn't previously see. Like all other
functions for setting a sysfs attribute, this function should return
the number of bytes processed, or a negative errno value. That's
why "ret" is initialized to "count". But vmbus_channel_set_cpu()
sets "ret" to zero if it succeeds, and the wrong value will be
returned. The original code correctly returned "count".
This problem would have been evident with a simple test of
writing to /sys/bus/vmbus/devices/<guid>/channels/<nn>/cpu.
Michael
> mutex_unlock(&vmbus_connection.channel_mutex);
> cpus_read_unlock();
> +
> return ret;
> }
> static VMBUS_CHAN_ATTR(cpu, 0644, target_cpu_show, target_cpu_store);
> diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> index 02a226bcf0ed..25e9e982f1b0 100644
> --- a/include/linux/hyperv.h
> +++ b/include/linux/hyperv.h
> @@ -1670,6 +1670,7 @@ int vmbus_send_tl_connect_request(const guid_t
> *shv_guest_servie_id,
> const guid_t *shv_host_servie_id);
> int vmbus_send_modifychannel(struct vmbus_channel *channel, u32 target_vp);
> void vmbus_set_event(struct vmbus_channel *channel);
> +int vmbus_channel_set_cpu(struct vmbus_channel *channel, u32 target_cpu);
>
> /* Get the start of the ring buffer. */
> static inline void *
> --
> 2.47.1
