Re: [RFC PATCH] uio_hv_generic: Fix sysfs creation path for ring buffer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 2/14/2025 10:41 PM, Stephen Hemminger wrote:
On Fri, 14 Feb 2025 08:41:57 +0100
Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:

On Fri, Feb 14, 2025 at 12:35:44PM +0530, Naman Jain wrote:


On 2/14/2025 12:21 PM, Greg Kroah-Hartman wrote:
On Fri, Feb 14, 2025 at 12:13:51PM +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 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
deferring sysfs creation till device gets initialized completely.

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

Ick, that's the issue, you shouldn't be manually creating sysfs files.
Have the driver core do it for you at the proper time, which should make
your logic much simpler, right?

Set the default attribute groups instead of manually creating this and
see if that works out better.

thanks,

greg k-h

Thanks for reviewing Greg. I tried this approach and here are my
observations:

What I could create with ATTRIBUTE_GROUPS:
/sys/bus/vmbus/devices/eb765408-105f-49b6-b4aa-c123b64d17d4/ring

The one we have right now:
/sys/bus/vmbus/devices/eb765408-105f-49b6-b4aa-c123b64d17d4/channels/6/ring

What is "channels" and "6" here?  Are they real devices or just a
directory name or something else?

I could not find a way to tweak attributes to create the "ring" under above
path. I could see the variations of sys_create_* which provides a
way to pass kobj and do that, but that is something we are already
using.

No driver should EVER be pointing to a raw kobject, that's a huge hint
that something is really wrong.  Also, if a raw kobject is in a device
path in the middle like this, it will not be seen properly from
userspace library tools :(

So again, what is creating the "channels" and "6" subdirectories?  All
of that shoudl be under full control by the uio device, right?

The original design of exposing channels was based on what the
network core does to expose queues. Worth comparing the two
to see if there is any shared insight.

Thanks Greg and Stephen. I'll try to find it.

Regards,
Naman




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux