linux-kernel - Re: [PATCH v2 1/2] rust: pci: skip probing VFs if driver doesn't support VFs

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: <20251003115226.GJ3299207@nvidia.com>
Date: Fri, 3 Oct 2025 08:52:26 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: John Hubbard <jhubbard@...dia.com>,
	Alexandre Courbot <acourbot@...dia.com>,
	Joel Fernandes <joelagnelf@...dia.com>,
	Timur Tabi <ttabi@...dia.com>, Alistair Popple <apopple@...dia.com>,
	Zhi Wang <zhiw@...dia.com>, Surath Mitra <smitra@...dia.com>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	Alex Williamson <alex.williamson@...hat.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Krzysztof Wilczyński <kwilczynski@...nel.org>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	nouveau@...ts.freedesktop.org, linux-pci@...r.kernel.org,
	rust-for-linux@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] rust: pci: skip probing VFs if driver doesn't
 support VFs

On Fri, Oct 03, 2025 at 02:57:53AM +0200, Danilo Krummrich wrote:

> Which ops pointer are you referring to? Do you mean the struct pci_driver
> pointer? If so, no we can't access this one. We could make it accessible, but it
> would result into horrible code, wouldn't make it possible to implement the
> check generically for any device (which we need anyways) and would have some
> other bad implications.

Yes pci_driver. You must confirm the attached driver is following the
right SRIOV protocol otherwise you can't claim the result is
bound. This is where we are with PCI today at least.

It sounds like you plan to come with patches changing how SRIOV
enablement works in PCI susbsytem, if that also comes with a way to
detect that the driver is following the rules without using pci_driver
then great.

But that would make me feel more strongly that this should be a core
helper and the existing users should be converted to the new mechanism
so we don't have two approaches here.

> Even if we'd make it accessible, the driver field within a module structure
> depends on the exact implementation, i.e. it depends on whether a module is
> declared "by hand", or whether it is generated by a module_driver!() macro (e.g.
> module_pci_driver!().

It is kind of a bad place to end up, drivers do occasionally use their
driver pointers for little things, like this for example. It is not
common but it is a technique..

Jason