linux-kernel - Re: [PATCH 3/8] rust: pci: add {enable,disable}

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: <aYULLucqol7jRoDC@earendel>
Date: Thu, 5 Feb 2026 16:27:10 -0500
From: Peter Colberg <pcolberg@...hat.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Danilo Krummrich <dakr@...nel.org>, 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>,
	Abdiel Janulgue <abdiel.janulgue@...il.com>,
	Daniel Almeida <daniel.almeida@...labora.com>,
	Robin Murphy <robin.murphy@....com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dave Ertman <david.m.ertman@...el.com>,
	Ira Weiny <ira.weiny@...el.com>, Leon Romanovsky <leon@...nel.org>,
	linux-pci@...r.kernel.org, rust-for-linux@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Alexandre Courbot <acourbot@...dia.com>,
	Alistair Popple <apopple@...dia.com>,
	Joel Fernandes <joelagnelf@...dia.com>,
	John Hubbard <jhubbard@...dia.com>, Zhi Wang <zhiw@...dia.com>
Subject: Re: [PATCH 3/8] rust: pci: add {enable,disable}_sriov(), to control
 SR-IOV capability

Hi Jason,

On Mon, Jan 05, 2026 at 09:22:36PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 23, 2025 at 02:17:12PM -0500, Peter Colberg wrote:
> > Further, enable_sriov() is prevented during remove() using a new
> > flag inhibit_enable in the pci_sriov structure that is set before
> > and cleared after the PF driver is unbound from the device.
> 
> Doesn't this need something concurrent safe like a revocable?

Thank you for the follow-up and apologies for the delay. I have now
posted a v2 series that takes a different approach from what was
described earlier, after discussing this further with Danilo.

In the v2 patch [1], when the new PCI driver flag managed_sriov is
set, which is always the case for Rust, SR-IOV is disabled twice if
needed: once before the unbind() callback for a well-behaved driver,
and a second time after unbind() for a broken (but nevertheless using
safe APIs only) driver that re-enables SR-IOV during unbind().

Together with commit a995fe1a3aa7 ("rust: driver: drop device private
data post unbind") which ensures that the device private data for the
PF device is still alive until after the function pci_iov_remove() is
called and forcibly re-disables SR_IOV if needed, this upholds the
safety guarantee which pci::Device::physfn() depends on.

As an alternative for preventing SR-IOV management during unbind(), I
briefly considered adding a new context, e.g., CoreInternal => Core =>
CoreUnbind => Bound => Normal, where {enable,disable}_sriov() are
implemented by Core but not CoreUnbind, but discarded that solution
since it seems too specific to this case to warrant the complexity.

Thanks,
Peter

[1] https://lore.kernel.org/rust-for-linux/20260205-rust-pci-sriov-v2-1-ef9400c7767b@redhat.com/

> 
> Jason
>