linux-kernel - Re: [PATCH v2] driver core: Check drivers

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]

Message-ID: <7C5EF578-B0CA-4FCB-86F7-470EDD27240D@nutanix.com>
Date: Wed, 15 Oct 2025 10:23:20 +0000
From: Vincent Liu <vincent.liu@...anix.com>
To: Bjorn Helgaas <helgaas@...nel.org>
CC: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "dakr@...nel.org" <dakr@...nel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "linux-pci@...r.kernel.org"
	<linux-pci@...r.kernel.org>
Subject: Re: [PATCH v2] driver core: Check drivers_autoprobe for all added
 devices

On 14 Oct 2025, at 21:07, Bjorn Helgaas <helgaas@...nel.org> wrote:
> 
>> In particular for the PCI devices, only
>> hot-plugged PCIe devices/VFs should be affected as the default value of
>> pci/drivers_autoprobe remains 1 and can only be cleared from userland.
> 
> I'm not sure what this last sentence is telling us.  Does
> "pci/drivers_autoprobe" refer to struct pci_sriov.drivers_autoprobe?
> If so, can you elaborate on the connection with struct
> subsys_private.drivers_autoprobe, which this patch tests?  I don't see
> anything in this patch related to pci_sriov.

No this patch has nothing to do with pci_sriov.drivers_autoprobe, this is
generic for all (pci) devices. pci/drivers_autoprobe refers to the
drivers_autoprobe sysfs attribute on the pci bus.

The last sentence is saying that this setting should only affect hot-plugged
devices because I think there is no way for pci/drivers_autoprobe to be 0 
for cold plugged devices? But thinking more about this, I don’t think this
adds much value to the commit message because the drivers_autoprobe
is not intended for cold-plugged devices anyway. I’ll remove it.

> As far as I can tell, this patch is generic with respect to
> conventional PCI vs PCIe.  If so, I'd use "PCI" everywhere instead of
> a mix of PCI and PCIe.

Yes you are right, this is generic. I used PCIe purely because of the
“hot-plugging”, but happy to use PCI everywhere.

> Add "()" after function names to make them easily recognizable as
> functions.
> 
> s/respsect/respect/
> s/but this should be the/which is the/  # maybe? not sure what you intend

Ok.

Below is a rephrased commit message to incorporate the feedback.

Thanks,
Vincent

-- >8 --

Subject: [PATCH v2] driver core: Check drivers_autoprobe for all added devices

When a device is hot-plugged, the drivers_autoprobe sysfs attribute is
not checked (at least for PCI devices). This means that
drivers_autoprobe is not working as intended, e.g. hot-plugged PCI
devices will still be autoprobed and bound to drivers even with
drivers_autoprobe disabled.

Make sure all devices check drivers_autoprobe by pushing the
drivers_autoprobe check into device_initial_probe(). This will only
affect devices on the PCI bus for now as device_initial_probe() is only
called by pci_bus_add_device() and bus_probe_device(), but
bus_probe_device() already checks for autoprobe, so callers of
bus_probe_device() should not observe changes on autoprobing.

Any future callers of device_initial_probe() will respect the
drivers_autoprobe sysfs attribute, which is the intended purpose of
drivers_autoprobe.

Signed-off-by: Vincent Liu <vincent.liu@...anix.com>

Link: https://lore.kernel.org/20251001151508.1684592-1-vincent.liu@nutanix.com