Re: [linux-next:master 3728/9137] samples/rust/rust_driver_auxiliary.o: warning: objtool: _RINvXs5_NtNtCshc5sK6KjdJJ_6kernel5alloc4kboxINtB6_3BoxINtNtNtCsbsbRiabPlh9_4core3mem12maybe_uninit11MaybeUninitINtNtBa_9auxiliary16RegistrationDataNtCseULRbgTYaTO_21rust_driver_auxiliary4DataEENtNtB...

["Alexandre Courbot" <acourbot@nvidia.com>]

On Fri May 29, 2026 at 9:13 PM JST, Gary Guo wrote:
> On Fri May 29, 2026 at 9:19 AM BST, Alexandre Courbot wrote:
>> On Fri May 29, 2026 at 5:00 PM JST, Alice Ryhl wrote:
>>> On Fri, May 29, 2026 at 9:54 AM Alexandre Courbot <acourbot@nvidia.com> wrote:
>>>>
>>>> On Fri May 29, 2026 at 3:35 PM JST, Alice Ryhl wrote:
>>>> > On Fri, May 29, 2026 at 10:52:52AM +0800, kernel test robot wrote:
>>>> >> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>>>> >> head:   f7af91adc230aa99e23330ecf85bc9badd9780ad
>>>> >> commit: fd3b87ff0232f46e1ad53a48609a3853c8757c6c [3728/9137] rust: auxiliary: add registration data to auxiliary devices
>>>> >> config: x86_64-randconfig-004-20260529 (https://download.01.org/0day-ci/archive/20260529/202605291041.seNEWvLQ-lkp@intel.com/config)
>
> Ah, OPTIMIZE_FOR_SIZE build, it's always this...
>
>>>> >> compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
>>>> >> rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
>>>> >> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260529/202605291041.seNEWvLQ-lkp@intel.com/reproduce)
>>>> >>
>>>> >> If you fix the issue in a separate patch/commit (i.e. not just a new version of
>>>> >> the same patch/commit), kindly add following tags
>>>> >> | Reported-by: kernel test robot <lkp@intel.com>
>>>> >> | Closes: https://lore.kernel.org/oe-kbuild-all/202605291041.seNEWvLQ-lkp@intel.com/
>>>> >>
>>>> >> All warnings (new ones prefixed by >>):
>>>> >>
>>>> >>    samples/rust/rust_driver_auxiliary.o: warning: objtool: asan.module_ctor+0xd: call without frame pointer save/setup
>>>> >>    samples/rust/rust_driver_auxiliary.o: warning: objtool: asan.module_dtor+0x1: call without frame pointer save/setup
>>>> >
>>>> > This one looks like this bug:
>>>> > https://github.com/rust-lang/rust/pull/156980
>>>>
>>>> Does [1] work around the problem by any chance?
>>>>
>>>> [1] https://lore.kernel.org/all/20260527-nova-exports-v2-3-06de4c556d55@nvidia.com/
>>>
>>> The asan.module_ctor error? I don't see how it would work around that.
>>
>> I was referring to this error on the report:
>>
>> _RINvXs5_NtNtCshc5sK6KjdJJ_6kernel5alloc4kboxINtB6_3BoxINtNtNtCsbsbRiabPlh9_4core3mem12maybe_uninit11MaybeUninitINtNtBa_9auxiliary16RegistrationDataNtCseULRbgTYaTO_21rust_driver_auxiliary4DataEENtNtB8_9allocator7KmallocEINtCs57PXBekmiam_8pin_init12InPlaceWriteB1L_E14write_pin_initNtNtBa_5error5ErrorINtNtB3y_10___internal11InitClosureNCINvYIBH_B1L_B35_EINtNtBa_4init11InPlaceInitB1L_E8pin_initB4u_IB4O_NCINvMsc_B1O_INtB1O_12RegistrationB2l_E3newNtNtBX_7convert10InfallibleB2l_Es_0B1L_B4u_EE0B1L_B4u_EEB2n_: symbol name too long, can't create __pfx_ symbol
>>
>> As this patch might help shorten the symbol.
>
> https://lore.kernel.org/rust-for-linux/20260527-pin-init-sync-v1-5-e20335ed2501@garyguo.net/
> would also help a bit with this, although I'm not sure if is sufficient.
>
> Also, regarding your patch; do you need `#[inline(always)]` or is `#[inline]`
> sufficient? Inlining shouldn't be forced unless there's a good justification.

So using the config file and base commit from the report, I get these 4 symbols:

samples/rust/rust_driver_auxiliary.o: warning: objtool: _RINvXs5_NtNtCs1EKtwoKEMO2_6kernel5alloc4kboxINtB6_3BoxINtNtNtCs1peUGmbrgHn_4core3mem12maybe_uninit11MaybeUninitINtNtBa_9auxiliary16RegistrationDataNtCsfAKt1AHk10R_21rust_driver_auxiliary4DataEENtNtB8_9allocator7KmallocEINtCsfxcgfq7FLKi_8pin_init12InPlaceWriteB1L_E14write_pin_initNtNtBa_5error5ErrorINtNtB3y_10___internal11InitClosureNCINvYIBH_B1L_B35_EINtNtBa_4init11InPlaceInitB1L_E8pin_initB4u_IB4O_NCINvMsc_B1O_INtB1O_12RegistrationB2l_E3newNtNtBX_7convert10InfallibleB2l_Es_0B1L_B4u_EE0B1L_B4u_EEB2n_: symbol name too long, can't create __pfx_ symbol
samples/rust/rust_debugfs_scoped.o: warning: objtool: _RINvMs0_NvNtNtCs1EKtwoKEMO2_6kernel4sync4lock1__INtB6_12___ThePinDataINtNtNtBc_5alloc4kvec3VecINtNtCs1peUGmbrgHn_4core3pin3PinINtNtB1a_4kbox3BoxINtNtBc_7debugfs5ScopeNtCsgkhUnUyOK5q_19rust_debugfs_scoped10DeviceDataENtNtB1a_9allocator7KmallocEEB3s_ENtNtB8_5mutex12MutexBackendE5stateNtNtB1z_7convert10InfallibleINtNtCsfxcgfq7FLKi_8pin_init10___internal11InitClosureNCINvMs5_NtBc_5typesINtB60_6OpaqueNtNtCsge5g75tgsAU_8bindings12bindings_raw5mutexE8ffi_initNCNCINvMs0_B8_INtB8_4LockB15_B3Z_E3newB15_E00E0B6b_B4x_EEB2G_: symbol name too long, can't create __pfx_ symbol
samples/rust/rust_debugfs_scoped.o: warning: objtool: _RINvXs5_NtNtCs1EKtwoKEMO2_6kernel5alloc4kboxINtB6_3BoxINtNtNtCs1peUGmbrgHn_4core3mem12maybe_uninit11MaybeUninitINtNtBa_7debugfs5ScopeNtCsgkhUnUyOK5q_19rust_debugfs_scoped10DeviceDataEENtNtB8_9allocator7KmallocEINtCsfxcgfq7FLKi_8pin_init12InPlaceWriteB1L_E14write_pin_initNtNtBa_5error5ErrorINtNtB3p_10___internal11InitClosureNCINvYIBH_B1L_B2W_EINtNtBa_4init11InPlaceInitB1L_E8pin_initNtNtBX_7convert10InfallibleINtB3p_12ChainPinInitIB4F_NCINvMs_B1O_B1L_3newB6a_NCINvMB1O_NtB1O_3Dir5scopeB27_B6a_NCNvB29_17create_file_writes0_0B27_E0B27_Es0_0B1L_B6a_ENCB73_0B1L_B6a_EE0B1L_B4l_EEB29_: symbol name too long, can't create __pfx_ symbol
samples/rust/rust_debugfs_scoped.o: warning: objtool: _RINvXs5_NtNtCs1EKtwoKEMO2_6kernel5alloc4kboxINtB6_3BoxINtNtNtCs1peUGmbrgHn_4core3mem12maybe_uninit11MaybeUninitINtNtBa_7debugfs5ScopeNtCsgkhUnUyOK5q_19rust_debugfs_scoped10ModuleDataEENtNtB8_9allocator7KmallocEINtCsfxcgfq7FLKi_8pin_init12InPlaceWriteB1L_E14write_pin_initNtNtBa_5error5ErrorINtNtB3p_10___internal11InitClosureNCINvYIBH_B1L_B2W_EINtNtBa_4init11InPlaceInitB1L_E8pin_initNtNtBX_7convert10InfallibleINtB3p_12ChainPinInitIB4F_NCINvMs_B1O_B1L_3newB6a_NCINvMB1O_NtB1O_3Dir5scopeB27_B6a_NCNvB29_12init_control0IB4F_NCNvMB29_B27_4inits_0B27_B6a_EE0B8k_Es0_0B1L_B6a_ENCB73_0B1L_B6a_EE0B1L_B4l_EEB29_: symbol name too long, can't create __pfx_ symbol

With [1], we are down to 1:

samples/rust/rust_debugfs_scoped.o: warning: objtool: _RINvMs0_NvNtNtCs1EKtwoKEMO2_6kernel4sync4lock1__INtB6_12___ThePinDataINtNtNtBc_5alloc4kvec3VecINtNtCs1peUGmbrgHn_4core3pin3PinINtNtB1a_4kbox3BoxINtNtBc_7debugfs5ScopeNtCsgkhUnUyOK5q_19rust_debugfs_scoped10DeviceDataENtNtB1a_9allocator7KmallocEEB3s_ENtNtB8_5mutex12MutexBackendE5stateNtNtB1z_7convert10InfallibleINtNtCsfxcgfq7FLKi_8pin_init10___internal11InitClosureNCINvMs5_NtBc_5typesINtB60_6OpaqueNtNtCsge5g75tgsAU_8bindings12bindings_raw5mutexE8ffi_initNCNCINvMs0_B8_INtB8_4LockB15_B3Z_E3newB15_E00E0B6b_B4x_EEB2G_: symbol name too long, can't create __pfx_ symbol

I also tried to apply the patch you listed, but it didn't apply on that
commit.

Now as you mentioned in [2], it is true that if we prevent the creation
of types beyond a certain complexity we are dooming ourselves to an
eternal game of whack-a-mole. Which leaves [1] somewhat in limbo as
that's the approach we were adopting to solve the same problem of
symbols that are too long for modpost.

[1] https://lore.kernel.org/all/20260527-nova-exports-v2-3-06de4c556d55@nvidia.com/
[2] https://lore.kernel.org/all/DIV7510GLW8P.1KP88LYA360IC@garyguo.net/