Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] NVKV decoder uses host-endian memory pointer casts and byte casting, breaking big-endian compatibility. --
--- Patch [3]: [PATCH 3/6] gpu: nova-core: add NVKV decoder --- commit 462ea319dececf0891b941e125a3a7cd586a70f8 Author: Eliot Courtney <[email protected]> gpu: nova-core: add NVKV decoder This commit adds a decoder for NVKV to process GMCAPI call messages from the GSP. It introduces a Schema visitor trait to process the (key, index, value) sequences from the encoded stream. > diff --git a/drivers/gpu/nova-core/gsp/nvkv/decode.rs > b/drivers/gpu/nova-core/gsp/nvkv/decode.rs > new file mode 100644 > index 0000000000000..ee8b6ab5a3a43 > --- /dev/null > +++ b/drivers/gpu/nova-core/gsp/nvkv/decode.rs [ ... ] > + fn take_u8s(&mut self, count: usize) -> Result<&[u8]> { > + let values = self.take_u64s(count.div_ceil(8))?; > + values.as_bytes().get(..count).ok_or(EINVAL) [Severity: High] Does casting a native [u64] to [u8] using as_bytes() expose the native byte order of the host? If the GSP sends data in little-endian format, won't this yield reversed 8-byte chunks on big-endian architectures? > + } > + > + fn take_u32s(&mut self, count: usize) -> Result<&[u32]> { > + let values = self.take_u64s(count.div_ceil(2))?; > + // SAFETY: `values` is 8 byte aligned and only 4 byte alignment is > required. All bit > + // patterns are valid for `u32`. > + Ok(unsafe { > core::slice::from_raw_parts(values.as_ptr().cast::<u32>(), count) }) [Severity: High] Could this raw pointer cast from u64 to u32 cause issues on big-endian systems? This appears to change the order of the 32-bit words compared to the original little-endian GSP message layout. > + } > + > + fn take_u64s(&mut self, count: usize) -> Result<&[u64]> { -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3
