Re: [RFC PATCH 2/2] kbuild: rust: use klint to provide CONFIG_FRAME_WARN

["Gary Guo" <gary@garyguo.net>]

On Wed Jan 28, 2026 at 12:31 AM GMT, Alexandre Courbot wrote:
> On Wed Jan 28, 2026 at 2:11 AM JST, Gary Guo wrote:
>> From: Gary Guo <gary@garyguo.net>
>>
>> klint is able to analyze frame size and warn on frames that are too big.
>>
>> With `register_tool(klint)` support, we can simply instruct rust to turn on
>> `klint::stack_frame_too_large`. This is a no-op if normal rustc (or Clippy)
>> is invoked, but will perform the check if klint is used.
>>
>> This is an example of a bug caught using this option:
>>
>> warning: stack size of `gsp::cmdq::Cmdq::new` is 8216 bytes, exceeds the 2048-byte limit
>>    --> drivers/gpu/nova-core/gsp/cmdq.rs:453:5
>>     |
>> 453 |     pub(crate) fn new(dev: &device::Device<device::Bound>) -> Result<Cmdq> {
>>     |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>     |
>>     = note: the stack size is inferred from instruction `sub $0x2018,%rsp` at .text+32778
>
> Initially this error puzzled me a bit since the objects directly built
> by Cmdq::new are not larger than ~40 bytes, but then I dug into the
> constructors it called and found that `PteArray`, a large struct, is
> built on the stack! We need to convert it to an `Init` I guess.
>
> Super valuable tool!

Yeah, I've already created a Zulip which mentions that the PTE array is likely
the root cause. This specific lint only concerns the final stack size and is not
aware of what's creating them.

It might be possible to do more detailed analysis by checking what is using the
stack (e.g. perhaps recovery variable -> stack slots using DWARF if full
debuginfo is enabled, or find out the instruction that first touches the
specific stack location and map it back like that), but doing so is quite tricky
and the marginal benefit is less than pointing out there's an issue to be
investigated in the first place.

Best,
Gary