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

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

[Alice Ryhl]

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)
> 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

Alice

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]

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)
>> 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/

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

[Alice Ryhl]

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)
> >> 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.

Alice

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]

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)
>> >> 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.

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

[Alice Ryhl]

On Fri, May 29, 2026 at 05:19:06PM +0900, 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)
> >> >> 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.

That is plausible.

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

[Gary Guo]

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.

Best,
Gary

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]

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.

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

[Gary Guo]

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.

Best,
Gary

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]

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?

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]

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.

I have tried to just `#[inline]` the problematic methods in [1] and at
least on my local config this results in a successful build. I can try
that for the next revision.

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

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]

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/

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

[Gary Guo]

On Fri May 29, 2026 at 3:08 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.
>
> 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.

Looks like the commit being built does not have pin-init-next integrated.
The symbol that you reported should not be present with latest pin-init changes.

I think we're looking at a solved issue again.

Best,
Gary