From: Jason Gunthorpe <jgg@nvidia.com>
To: Danilo Krummrich <dakr@kernel.org>
Cc: "John Hubbard" <jhubbard@nvidia.com>,
"Zhi Wang" <zhiw@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Alexandre Courbot" <acourbot@nvidia.com>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
"Surath Mitra" <smitra@nvidia.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"rust-for-linux@vger.kernel.org" <rust-for-linux@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"Alex Williamson" <alex.williamson@redhat.com>
Subject: Re: [PATCH 0/2] rust: pci: expose is_virtfn() and reject VFs in nova-core
Date: Thu, 2 Oct 2025 09:32:44 -0300 [thread overview]
Message-ID: <20251002123244.GF3195801@nvidia.com> (raw)
In-Reply-To: <DD7TP31FEE92.2E0AKAHUOHVVF@kernel.org>
On Thu, Oct 02, 2025 at 02:08:27PM +0200, Danilo Krummrich wrote:
> Why? What about other upstream drivers that clearly assert that they don't
> support VFs?
They shouldn't be doing that either. There is lots of junk in Linux,
that doesn't mean it should be made first-class to encourage more
people to do the wrong thing.
> Why would we want to force them to try to boot to a point where
> they "naturally" fail?
We want them to work.
> https://elixir.bootlin.com/linux/v6.17/source/drivers/net/ethernet/realtek/rtase/rtase_main.c#L2195
> https://elixir.bootlin.com/linux/v6.17/source/drivers/net/ethernet/intel/ice/ice_main.c#L5266
> https://elixir.bootlin.com/linux/v6.17/source/drivers/net/ethernet/intel/igb/igb_main.c#L3221
This usage seems wrong to me:
commit 50ac7479846053ca8054be833c1594e64de496bb
Author: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Date: Wed Jul 28 12:39:10 2021 -0700
ice: Prevent probing virtual functions
The userspace utility "driverctl" can be used to change/override the
system's default driver choices. This is useful in some situations
(buggy driver, old driver missing a device ID, trying a workaround,
etc.) where the user needs to load a different driver.
However, this is also prone to user error, where a driver is mapped
to a device it's not designed to drive. For example, if the ice driver
is mapped to driver iavf devices, the ice driver crashes.
Add a check to return an error if the ice driver is being used to
probe a virtual function.
Decoding this.. There is actually an "iavf" driver, and it does have
special PCI IDs for VFs:
static const struct pci_device_id iavf_pci_tbl[] = {
{PCI_VDEVICE(INTEL, IAVF_DEV_ID_VF), 0},
{PCI_VDEVICE(INTEL, IAVF_DEV_ID_VF_HV), 0},
{PCI_VDEVICE(INTEL, IAVF_DEV_ID_X722_VF), 0},
{PCI_VDEVICE(INTEL, IAVF_DEV_ID_ADAPTIVE_VF), 0},
In normal cases iavf will probe to the SRIOV VFS just fine.
The above is saying if the user mis-uses driverctl to bind the ice
driver to a function that doesn't have matching PCI IDs then the
kernel crashes. Yeah. I'm pretty sure that is true for a lot of
drivers. Bind them to HW not in their ID tables and their are not
going to work right.
I would have rejected a patch like this. The ID table is already
correct and properly excludes VFs.
Jason
next prev parent reply other threads:[~2025-10-02 12:32 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-30 22:07 [PATCH 0/2] rust: pci: expose is_virtfn() and reject VFs in nova-core John Hubbard
2025-09-30 22:07 ` [PATCH 1/2] rust: pci: add is_virtfn(), to check for VFs John Hubbard
2025-10-01 0:30 ` Alistair Popple
2025-09-30 22:07 ` [PATCH 2/2] gpu: nova-core: reject binding to SR-IOV Virtual Functions John Hubbard
2025-10-01 0:33 ` Alistair Popple
2025-10-01 1:26 ` John Hubbard
2025-10-01 0:26 ` [PATCH 0/2] rust: pci: expose is_virtfn() and reject VFs in nova-core Alexandre Courbot
2025-10-01 1:26 ` John Hubbard
2025-10-01 1:39 ` Alexandre Courbot
2025-10-01 1:45 ` John Hubbard
2025-10-01 8:09 ` Zhi Wang
2025-10-01 14:48 ` Jason Gunthorpe
2025-10-01 21:13 ` Zhi Wang
2025-10-02 1:43 ` Alexandre Courbot
2025-10-02 1:50 ` John Hubbard
2025-10-02 11:58 ` Jason Gunthorpe
2025-10-02 12:59 ` Zhi Wang
2025-10-02 13:42 ` Jason Gunthorpe
2025-10-02 14:29 ` Zhi Wang
2025-10-02 14:31 ` Jason Gunthorpe
2025-10-07 6:51 ` Zhi Wang
2025-10-07 10:14 ` Danilo Krummrich
2025-10-07 11:00 ` Zhi Wang
2025-10-07 11:26 ` Jason Gunthorpe
2025-10-01 14:46 ` Jason Gunthorpe
2025-10-01 18:16 ` Alex Williamson
2025-10-01 18:30 ` Jason Gunthorpe
2025-10-01 22:35 ` John Hubbard
2025-10-02 7:41 ` Zhi Wang
2025-10-01 0:29 ` Alistair Popple
2025-10-01 1:22 ` John Hubbard
2025-10-01 10:32 ` Danilo Krummrich
2025-10-01 13:52 ` Zhi Wang
2025-10-01 22:38 ` John Hubbard
2025-10-01 22:52 ` Danilo Krummrich
2025-10-01 23:00 ` John Hubbard
2025-10-01 23:47 ` Joel Fernandes
2025-10-01 23:51 ` John Hubbard
2025-10-01 23:55 ` Danilo Krummrich
2025-10-02 0:48 ` Joel Fernandes
2025-10-02 0:54 ` John Hubbard
2025-10-02 12:05 ` Jason Gunthorpe
2025-10-02 12:01 ` Jason Gunthorpe
2025-10-02 12:08 ` Danilo Krummrich
2025-10-02 12:32 ` Jason Gunthorpe [this message]
2025-10-02 12:41 ` Danilo Krummrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251002123244.GF3195801@nvidia.com \
--to=jgg@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=alex.williamson@redhat.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=smitra@nvidia.com \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=zhiw@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.