From: sashiko-bot@kernel.org
To: "Zhi Wang" <zhiw@nvidia.com>
Cc: linux-pci@vger.kernel.org, ojeda@kernel.org, gary@garyguo.net
Subject: Re: [PATCH v2 7/8] rust: pci: add typed SR-IOV PF registration data
Date: Thu, 24 Sep 2026 19:27:21 +0000 [thread overview]
Message-ID: <20260924192721.F1BF11F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260924190556.1620886-8-zhiw@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] rust: pci: missing #[inline] on C-binding forwarders and small accessors
--
commit f12a8908c8b58a535a5ede56fdb4d45436a0f800
Author: Zhi Wang <zhiw@nvidia.com>
rust: pci: add typed SR-IOV PF registration data
This commit adds VfRegistration to register a pinned Rust object in the PF's
driver data. It provides accessors for VF drivers to borrow this object after
checking the requested Rust type.
> diff --git a/rust/kernel/pci.rs b/rust/kernel/pci.rs
> index cb3ed2207075e..831b76744a30a 100644
> --- a/rust/kernel/pci.rs
> +++ b/rust/kernel/pci.rs
[ ... ]
> /// Returns the number of Virtual Functions (VF) enabled for a Physical Function (PF).
> #[cfg(CONFIG_PCI_IOV)]
> - pub(crate) fn num_vf(&self) -> i32 {
> + pub fn num_vf(&self) -> i32 {
[Severity: Low]
Should this function have an #[inline] attribute?
According to the Rust subsystem guidelines, functions in the kernel
abstraction crate that are small or forward to a C binding call should be
annotated with #[inline] to allow the optimizer to inline them across crate
boundaries.
> // SAFETY: `self.as_raw` is a valid pointer to a `struct pci_dev`.
> unsafe { bindings::pci_num_vf(self.as_raw()) }
> }
> diff --git a/rust/kernel/pci/sriov.rs b/rust/kernel/pci/sriov.rs
> new file mode 100644
> index 0000000000000..90abe878f67c5
> --- /dev/null
> +++ b/rust/kernel/pci/sriov.rs
[ ... ]
> +impl<Ctx: device::DeviceContext> PciDevice<Ctx> {
> + /// Returns the raw `vf_registration_data_rust` pointer from this device.
> + fn vf_registration_data_rust(&self) -> *mut core::ffi::c_void {
[Severity: Low]
Would it be appropriate to mark this small, trivial accessor with #[inline]?
> + // SAFETY: `self.as_raw()` is valid.
> + unsafe { (*self.as_raw()).vf_registration_data_rust }
> + }
> +
> + /// Sets the `vf_registration_data_rust` pointer on this device.
> + fn set_vf_registration_data_rust(&self, ptr: *mut core::ffi::c_void) {
[Severity: Low]
Could this trivial setter also benefit from an #[inline] annotation?
> + // SAFETY: `self.as_raw()` is valid. PCI probe publishes the data before enabling VFs;
> + // teardown removes all VFs before withdrawing it.
> + unsafe { (*self.as_raw()).vf_registration_data_rust = ptr };
> + }
> +}
> +
> +impl PciDevice<device::Bound> {
> + /// Returns the PF for this VF, or [`ENODEV`] if this is not a VF.
> + fn physfn(&self) -> Result<&PciDevice> {
[Severity: Low]
Should #[inline] be added here?
This is a short function reading a C struct field within the abstraction crate.
> + if !self.is_virtfn() {
> + return Err(ENODEV);
> + }
[ ... ]
> + pub fn vf_registration_data_with<F: ForLt + 'static, R>(
> + &self,
> + f: impl for<'borrow, 'data> FnOnce(Pin<&'borrow F::Of<'data>>) -> R,
> + ) -> Result<R> {
[Severity: Low]
Is it worth annotating this forwarding function with #[inline]?
> + // SAFETY: The higher-ranked closure prevents the borrow from escaping or being stored in
> + // invariant data by keeping its lifetime independent of the erased data lifetime.
> + let pinned = unsafe { self.vf_registration_data_pinned::<F>()? };
> + Ok(f(pinned))
> + }
> +
> + /// Returns a pinned reference to the VF registration data.
> + ///
> + /// Available only when `F` implements [`CovariantForLt`](trait@crate::types::CovariantForLt),
> + /// guaranteeing that shortening the PF data lifetime is sound.
> + ///
> + /// For non-covariant types, use [`Self::vf_registration_data_with()`].
> + ///
> + /// It returns the same errors as [`Self::vf_registration_data_with()`].
> + pub fn vf_registration_data<F: CovariantForLt + 'static>(&self) -> Result<Pin<&F::Of<'_>>> {
[Severity: Low]
Could this 1-line wrapper that delegates to vf_registration_data_pinned
also use #[inline]?
> + // SAFETY: `CovariantForLt` permits shortening the encoded lifetime to this borrow.
> + unsafe { self.vf_registration_data_pinned::<F>() }
> + }
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260924190556.1620886-1-zhiw@nvidia.com?part=7
next prev parent reply other threads:[~2026-09-24 19:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 19:05 [PATCH v2 0/8] Add Rust PCI SR-IOV support Zhi Wang
2026-09-24 19:05 ` [PATCH v2 1/8] rust: pci: add {enable,disable}_sriov(), to control SR-IOV capability Zhi Wang
2026-09-24 19:20 ` sashiko-bot
2026-09-25 20:43 ` Peter Colberg
2026-09-28 19:32 ` Zhi Wang
2026-09-27 16:37 ` Danilo Krummrich
2026-09-28 19:45 ` Zhi Wang
2026-09-24 19:05 ` [PATCH v2 2/8] rust: pci: add vtable attribute to pci::Driver trait Zhi Wang
2026-09-24 19:13 ` sashiko-bot
2026-09-24 19:05 ` [PATCH v2 3/8] rust: pci: add is_virtfn(), to check for VFs Zhi Wang
2026-09-24 19:14 ` sashiko-bot
2026-09-24 19:05 ` [PATCH v2 4/8] rust: pci: add is_physfn(), to check for PFs Zhi Wang
2026-09-24 19:12 ` sashiko-bot
2026-09-24 19:05 ` [PATCH v2 5/8] rust: pci: add num_vf(), to return number of VFs Zhi Wang
2026-09-24 19:13 ` sashiko-bot
2026-09-24 19:05 ` [PATCH v2 6/8] rust: pci: add bus callback sriov_configure(), to control SR-IOV from sysfs Zhi Wang
2026-09-24 19:19 ` sashiko-bot
2026-09-24 19:05 ` [PATCH v2 7/8] rust: pci: add typed SR-IOV PF registration data Zhi Wang
2026-09-24 19:27 ` sashiko-bot [this message]
2026-09-28 20:08 ` Danilo Krummrich
2026-09-29 7:27 ` Zhi Wang
2026-09-29 8:35 ` Danilo Krummrich
2026-09-24 19:05 ` [PATCH v2 8/8] samples: rust: add Rust SR-IOV VF driver sample Zhi Wang
2026-09-24 19:22 ` sashiko-bot
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=20260924192721.F1BF11F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=gary@garyguo.net \
--cc=linux-pci@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox