linux-kernel - Re: [PATCH v2] uio_hv_generic: Fix sysfs creation path for ring buffer

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] [day] [month] [year] [list]

Message-ID: <2025031859-overwrite-tidy-f8ef@gregkh>
Date: Tue, 18 Mar 2025 14:28:48 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Naman Jain <namjain@...ux.microsoft.com>
Cc: "K . Y . Srinivasan" <kys@...rosoft.com>,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	Wei Liu <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>,
	Stephen Hemminger <stephen@...workplumber.org>,
	linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
	stable@...nel.org, Saurabh Sengar <ssengar@...ux.microsoft.com>,
	Michael Kelley <mhklinux@...look.com>
Subject: Re: [PATCH v2] uio_hv_generic: Fix sysfs creation path for ring
 buffer

On Tue, Mar 18, 2025 at 11:45:58AM +0530, Naman Jain wrote:
> On regular bootup, devices get registered to vmbus first, so when
> uio_hv_generic driver for a particular device type is probed,
> the device is already initialized and added, so sysfs creation in
> uio_hv_generic probe works fine. However, when device is removed
> and brought back, the channel rescinds and device again gets
> registered to vmbus. However this time, the uio_hv_generic driver is
> already registered to probe for that device and in this case sysfs
> creation is tried before the device gets initialized completely.
> 
> Fix this by moving the core logic of sysfs creation for ring buffer,
> from uio_hv_generic to HyperV's vmbus driver, where rest of the sysfs
> attributes for the channels are defined. While doing that, make use
> of attribute groups and macros, instead of creating sysfs directly,
> to ensure better error handling and code flow. While at it, configure
> size of ring sysfs based on ring buffer's actual size and not 2MB default.

When you say stuff like "while at it..." that's a huge hint that the
patch should be broken up into smaller pieces and made a patch series.

> Problem path:
> vmbus_device_register
>     device_register
>         uio_hv_generic probe
>                     sysfs_create_bin_file (fails here)

Why does it fail?

>         kset_create_and_add (dependency)
>         vmbus_add_channel_kobj (dependency)

I don't understand this "graph", sorry.

> +/*
> + * hv_create_ring_sysfs - create ring sysfs entry corresponding to ring buffers for a channel
> + */

Kerneldoc?

> +int hv_create_ring_sysfs(struct vmbus_channel *channel,
> +			 int (*hv_mmap_ring_buffer)(struct vmbus_channel *channel,
> +						    struct vm_area_struct *vma))
> +{
> +	struct kobject *kobj = &channel->kobj;
> +
> +	channel->mmap_ring_buffer = hv_mmap_ring_buffer;
> +	channel->ring_sysfs_visible = true;
> +	return sysfs_update_group(kobj, &vmbus_chan_group);
> +}
> +EXPORT_SYMBOL_GPL(hv_create_ring_sysfs);

You just raced userspace and created a file without telling it that it
showed up, right?  Something still feels really wrong here.

greg k-h