Re: [PATCH 2/7] scripts: modpost: increase buf_printf's buffer size

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

On Wed May 20, 2026 at 3:44 AM BST, Alexandre Courbot wrote:
> Hi Gary,
>
> On Fri May 1, 2026 at 10:02 PM JST, Gary Guo wrote:
>> On Thu Apr 30, 2026 at 3:55 PM BST, Alexandre Courbot wrote:
>>> Rust tends to produce long symbol names; when trying to export symbols
>>> from nova-core for nova-drm to link to, the 500 bytes of the internal
>>> buffer used for symbol name formatting are not enough, making modpost
>>> fail.
>>>
>>> Fix this by increasing the size of the buffer used to format the symbols
>>> to 1024 bytes. It is a stack buffer, but modpost is a user-space program
>>> so that shouldn't be a problem.
>>
>> I think we should make sure all constants related to symbol names match.
>> KSYM_NAME_LEN is 512 so this should just be that.
>
> Do you mean we should use `KSYM_NAME_LEN` for the size of `tmp`? The
> formatted strings can be longer than the symbol name alone (see the
> example below which wraps it into `KSYMTAB_FUNC()`), so this should
> probably be `KSYM_NAME_LEN + something` if we align to it.
>
>>
>> The only case that I've been hit with very long symbol names so far is doc tests.
>> Can you provide an example of the case where you're hit with very long symbol
>> names in Nova? In many cases they're just functions that are supposed to be
>> inlined but isn't.
>
> Here is an example string that doesn't make it, it doesn't seem related
> to doctests but also doesn't occur on all configs:
>
> ERROR: modpost: buf_printf output was truncated for string
> KSYMTAB_FUNC(_RINvXs5_NtNtCs1EKtwoKEMO2_6kernel5alloc4kboxINtB6_3BoxINtNtNtCs1peUGmbrgHn_4core3mem12maybe_uninit11MaybeUninitINtNtBa_9auxiliary16RegistrationDataNtNtCs6wA3Ay79aUn_9nova_core6driver7AuxDataEENtNtB8_9allocator7KmallocEINtCsfxcgfq7FLKi_8pin_init12InPlaceWriteB1L_E14write_pin_initNtNtBa_5error5ErrorINtNtB3x_10___internal11InitClosureNCINvYIBH_B1L_B34_EINtNtBa_4init11InPlaceInitB1L_E8pin_initB4t_IB4N_NCINvMsd_B1O_INtB1O_12RegistrationINtNtNtBa_5types6for_lt15UnsafeForLtImplDG_INtB72_:

`InPlaceWrite` should definitely be inline as you pointed out in the reply. I
have some pin_init symbol length opt planned as well.

It also looks like this has to do with the fact that the type being generated
with `ForLt` macro being overly complex. Perhaps `define_for_lt!` is a better
approach.

Best,
Gary

> 608 bytes needed, 500 available