Re: [PATCH] gpu: nova-core: firmware: fwsec: use zeroed() to zero-pad buffers

[Alexandre Courbot]

On Wed Oct 7, 2026 at 5:42 PM JST, Danilo Krummrich wrote:
> On Wed Oct 7, 2026 at 2:33 AM CEST, Alexandre Courbot wrote:
>> On Wed Oct 7, 2026 at 7:20 AM JST, Danilo Krummrich wrote:
>>> On Tue Oct 6, 2026 at 12:04 PM CEST, Thorsten Blum wrote:
>>>> -            let mut ucode = KVec::with_capacity(aligned_code_size, GFP_KERNEL)?;
>>>> -            ucode.extend_from_slice(code, GFP_KERNEL)?;
>>>> -            ucode.resize(aligned_code_size, 0, GFP_KERNEL)?;
>>>> -
>>>> +            let mut ucode = KVec::zeroed(aligned_code_size, GFP_KERNEL)?;
>>>> +            ucode[..code.len()].copy_from_slice(code);
>>>
>>> I kinda dislike that this is now a potential panic, but it does better express
>>> the intent.
>>
>> IMHO the original code expresses the intent just as well, and avoids
>> writing the area covered by `code` twice, on top of not introducing a
>> potential panic site.
>
> I'm referring to the fact that the original code expresses "I may allocate"
> three times, while the intent is that the allocation is exactly
> aligned_code_size.
>
> This is much more clear with the new code, if we really want to avoid a
> potential panic here, we could use get_mut(), but the ergonomics isn't great.
>
> That said, I wouldn't mind adding something like Vec::extend_within_capacity(),
> which fails if there's not enough capacity.

You know how I feel about panic sites in the code, even if they appear
to be untaken today. :)

Another thing we could do is replace `KVec::with_capacity` with
`KVec::new`, removing one potential allocation site. The added padding
(which in practice is likely to be 0-sized per the comment in the code)
is unlikely to trigger a resize anyway.