From: sashiko-bot@kernel.org
To: acourbot@nvidia.com, dakr@kernel.org, "Zhi Wang" <zhiw@nvidia.com>
Cc: ecourtney@nvidia.com, joelagnelf@nvidia.com,
"Alexandre Courbot" <acourbot@nvidia.com>,
boqun.feng@gmail.com, zhiwang@kernel.org,
linux-kernel@vger.kernel.org, a.hindborg@kernel.org,
apopple@nvidia.com, cjia@nvidia.com, smitra@nvidia.com,
airlied@gmail.com, ankita@nvidia.com, aniketa@nvidia.com,
tmgross@umich.edu, alkumar@nvidia.com, gary@garyguo.net,
kjaju@nvidia.com, kwankhede@nvidia.com,
"Danilo Krummrich" <dakr@kernel.org>,
ojeda@kernel.org, targupta@nvidia.com, lossin@kernel.org,
bjorn3_gh@protonmail.com, nova-gpu@lists.linux.dev,
alex.gaynor@gmail.com, simona@ffwll.ch, jhubbard@nvidia.com,
aliceryhl@google.com
Subject: Re: [PATCH v5 6/6] gpu: nova-core: reserve vGPU WPR2 heap
Date: Wed, 22 Jul 2026 07:52:34 +0000 [thread overview]
Message-ID: <20260722075235.5C9E91F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260722073913.1807677-7-zhiw@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unchecked subtractions during framebuffer layout calculation can underflow if the device's video memory size is unexpectedly small.
--
--- Patch [6]: [PATCH v5 6/6] gpu: nova-core: reserve vGPU WPR2 heap ---
commit f23fa75b7168b0143fdda0d52c83938a849ca02d
Author: Zhi Wang <zhiw@nvidia.com>
gpu: nova-core: reserve vGPU WPR2 heap
This commit updates the framebuffer layout calculation to pass the detected
vGPU state. It keeps baremetal boots on the existing heap sizing path and
uses a firmware-dependent 570.144 vGPU default heap binding when vGPU is
enabled.
> diff --git a/drivers/gpu/nova-core/fb.rs b/drivers/gpu/nova-core/fb.rs
> --- a/drivers/gpu/nova-core/fb.rs
> +++ b/drivers/gpu/nova-core/fb.rs
[ ... ]
> @@ -234,10 +240,19 @@ pub(crate) fn new(chipset: Chipset, bar: Bar0<'_>, gsp_fw: &GspFirmware) -> Resu
> FbRange(elf_addr..elf_addr + elf_size)
> };
>
> + let (vf_partition_count, wpr2_heap_size) = match vgpu_state {
> + VgpuState::Disabled => (
> + 0,
> + gsp::LibosParams::from_chipset(chipset).wpr_heap_size(chipset, fb.end)?,
> + ),
> + VgpuState::Enabled { total_vfs } => (
> + u8::try_from(total_vfs.get()).map_err(|_| EINVAL)?,
> + gsp::LibosParams::vgpu_wpr_heap_size(),
> + ),
> + };
> +
> let wpr2_heap = {
> const WPR2_HEAP_DOWN_ALIGN: Alignment = Alignment::new::<SZ_1M>();
> - let wpr2_heap_size =
> - gsp::LibosParams::from_chipset(chipset).wpr_heap_size(chipset, fb.end)?;
> let wpr2_heap_addr = (elf.start - wpr2_heap_size).align_down(WPR2_HEAP_DOWN_ALIGN);
[Severity: High]
This is a pre-existing issue, but could this subtraction underflow if the
hardware or a hypervisor reports a malformed, undersized framebuffer?
Since this patch introduces a hardcoded ~581MB requirement for
wpr2_heap_size in vGPU mode, the risk seems significantly amplified. If the
hardware-reported video memory size isn't large enough to contain the
bootloader, elf, and this new large heap, elf.start - wpr2_heap_size will
either panic or wrap around to a massive out-of-bounds address.
Should there be a validation check against the total fb_size before
allocating these ranges backwards from the end of the framebuffer?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260722073913.1807677-1-zhiw@nvidia.com?part=6
prev parent reply other threads:[~2026-07-22 7:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 7:39 [PATCH v5 0/6] gpu: nova-core: boot GSP with vGPU enabled Zhi Wang
2026-07-22 7:39 ` [PATCH v5 1/6] PCI/IOV: Return unsigned int from pci_sriov_get_totalvfs() Zhi Wang
2026-07-22 7:49 ` sashiko-bot
2026-07-22 7:39 ` [PATCH v5 2/6] rust: pci: add sriov_get_totalvfs() helper Zhi Wang
2026-07-22 7:52 ` sashiko-bot
2026-07-22 7:39 ` [PATCH v5 3/6] gpu: nova-core: read vGPU mode from FSP via PRC protocol Zhi Wang
2026-07-22 7:39 ` [PATCH v5 4/6] gpu: nova-core: detect and store vGPU state Zhi Wang
2026-07-22 7:39 ` [PATCH v5 5/6] gpu: nova-core: set RMSetSriovMode for vGPU Zhi Wang
2026-07-22 7:52 ` sashiko-bot
2026-07-22 7:39 ` [PATCH v5 6/6] gpu: nova-core: reserve vGPU WPR2 heap Zhi Wang
2026-07-22 7:52 ` sashiko-bot [this message]
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=20260722075235.5C9E91F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=alkumar@nvidia.com \
--cc=aniketa@nvidia.com \
--cc=ankita@nvidia.com \
--cc=apopple@nvidia.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=cjia@nvidia.com \
--cc=dakr@kernel.org \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=kjaju@nvidia.com \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=ojeda@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=simona@ffwll.ch \
--cc=smitra@nvidia.com \
--cc=targupta@nvidia.com \
--cc=tmgross@umich.edu \
--cc=zhiw@nvidia.com \
--cc=zhiwang@kernel.org \
/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.