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 10:31 PM JST, Gary Guo wrote:
> On Fri May 29, 2026 at 2:09 PM BST, Alexandre Courbot wrote:
>> 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.
>>
>> If the code is not inlined, we risk a build failure - pretty similarly
>> to the link errors of `build_assert!`. I'd say that justifies using
>> `#[inline(always)]` here, but maybe we should also add a comment
>> explaining why we do so.
>
> I think for long symbol names it's a very difference argument. There're many ways to
> create complex types that can lead to those. With this logic every generic code
> needs to be `#[inline(always)]`, which obviously is not what we want.

In that case, should we just increase the maximum allowed length of symbols?