[linux-next:master 4752/13171] error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`

[linux-next:master 4752/13171] error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`

[kernel test robot]

Hi Andreas,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head:   95cb2fd6ce0ad61af54191fe5ef271d7177f9c3a
commit: 0b08fc292842a13aa496413b48c1efb83573b8c6 [4752/13171] rust: introduce module_param module
config: arm64-randconfig-001-20251202 (https://download.01.org/0day-ci/archive/20251202/202512020454.Tf36WHw5-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project b3428bb966f1de8aa48375ffee0eba04ede133b7)
rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251202/202512020454.Tf36WHw5-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/202512020454.Tf36WHw5-lkp@intel.com/

All errors (new ones prefixed by >>):

>> error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`
   --> rust/kernel/module_param.rs:78:46
   |
   78 |         let container = unsafe { &*((*param).__bindgen_anon_1.arg.cast::<SetOnce<T>>()) };
   |                                              ^^^^^^^^^^^^^^^^ unknown field
   |
   = note: available field is: `_address`

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [linux-next:master 4752/13171] error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`

[Daniel Gomez]

On 01/12/2025 21.20, kernel test robot wrote:
> Hi Andreas,
> 
> FYI, the error/warning still remains.
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head:   95cb2fd6ce0ad61af54191fe5ef271d7177f9c3a
> commit: 0b08fc292842a13aa496413b48c1efb83573b8c6 [4752/13171] rust: introduce module_param module
> config: arm64-randconfig-001-20251202 (https://download.01.org/0day-ci/archive/20251202/202512020454.Tf36WHw5-lkp@intel.com/config)
> compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project b3428bb966f1de8aa48375ffee0eba04ede133b7)
> rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251202/202512020454.Tf36WHw5-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/202512020454.Tf36WHw5-lkp@intel.com/
> 
> All errors (new ones prefixed by >>):
> 
>>> error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`
>    --> rust/kernel/module_param.rs:78:46
>    |
>    78 |         let container = unsafe { &*((*param).__bindgen_anon_1.arg.cast::<SetOnce<T>>()) };
>    |                                              ^^^^^^^^^^^^^^^^ unknown field
>    |
>    = note: available field is: `_address`
> 

I can't replicate this issue either.

I've added these patches to fix other unrelated build issues, so, I'm not sure
how 0day ended up skipping them? Perhaps it uses head 95cb2fd6c? + bisect?

a74b6c0e53a6d um: Don't rename vmap to kernel_vmap
f74cf399e02e2 rust: debugfs: Replace the usage of Rust native atomics 
013f912eb5fa7 rust: sync: atomic: Implement Debug for Atomic<Debug> 
14e9a18b07ec4 rust: sync: atomic: Make Atomic*Ops pub(crate)

My testing branch:
https://git.kernel.org/pub/scm/linux/kernel/git/da.gomez/linux.git/log/?h=20251202-0day-test-0b08fc292842-with-fixes

FWIW, this is what I've tried:

rustc --version --verbose
rustc 1.88.0 (6b00bc388 2025-06-23)
binary: rustc
commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
commit-date: 2025-06-23
host: x86_64-unknown-linux-gnu
release: 1.88.0
LLVM version: 20.1.5

bindgen --version --verbose
bindgen 0.72.1
Clang: Debian clang version 21.1.5 (1)

rm -rfv build_dir/
mkdir -p build_dir/
wget https://download.01.org/0day-ci/archive/20251202/202512020454.Tf36WHw5-lkp@intel.com/config -O build_dir/.config

COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang-22 ~/lkp-tests/kbuild/make.cross W=1 O=build_dir ARCH=arm64 rustavailable
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang-22 ~/lkp-tests/kbuild/make.cross W=1 O=build_dir ARCH=arm64 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang-22 ~/lkp-tests/kbuild/make.cross W=1 O=build_dir ARCH=arm64 prepare
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang-22 ~/lkp-tests/kbuild/make.cross W=1 O=build_dir ARCH=arm64 -j$(nproc)

grep -i "bindgen\|rustc\|llv\|clang" build_dir/.config
CONFIG_CC_VERSION_TEXT="ClangBuiltLinux clang version 22.0.0git (https://github.com/llvm/llvm-project.git e19fa930ca838715028c00c234874d1db4f93154)"
CONFIG_CC_IS_CLANG=y
CONFIG_CLANG_VERSION=220000
CONFIG_AS_IS_LLVM=y
CONFIG_RUSTC_VERSION=108800
CONFIG_RUSTC_LLVM_VERSION=200105
CONFIG_RUSTC_HAS_COERCE_POINTEE=y
CONFIG_RUSTC_HAS_SPAN_FILE=y
CONFIG_RUSTC_HAS_UNNECESSARY_TRANSMUTES=y
CONFIG_RUSTC_VERSION_TEXT="rustc 1.88.0 (6b00bc388 2025-06-23)"
CONFIG_BINDGEN_VERSION_TEXT="bindgen 0.72.1"
CONFIG_RUSTC_SUPPORTS_ARM64=y
CONFIG_CLANG_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
CONFIG_HAS_LTO_CLANG=y
# CONFIG_LTO_CLANG_THIN is not set
CONFIG_HAVE_CFI_ICALL_NORMALIZE_INTEGERS_RUSTC=y

Build succeeds without issues (warnings, yes).

Re: [linux-next:master 4752/13171] error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`

[Oliver Sang]

hi, Daniel Gomez,

On Tue, Dec 02, 2025 at 10:02:02PM +0100, Daniel Gomez wrote:
> 
> 
> On 01/12/2025 21.20, kernel test robot wrote:
> > Hi Andreas,
> > 
> > FYI, the error/warning still remains.
> > 
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > head:   95cb2fd6ce0ad61af54191fe5ef271d7177f9c3a
> > commit: 0b08fc292842a13aa496413b48c1efb83573b8c6 [4752/13171] rust: introduce module_param module
> > config: arm64-randconfig-001-20251202 (https://download.01.org/0day-ci/archive/20251202/202512020454.Tf36WHw5-lkp@intel.com/config)
> > compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project b3428bb966f1de8aa48375ffee0eba04ede133b7)
> > rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251202/202512020454.Tf36WHw5-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/202512020454.Tf36WHw5-lkp@intel.com/
> > 
> > All errors (new ones prefixed by >>):
> > 
> >>> error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`
> >    --> rust/kernel/module_param.rs:78:46
> >    |
> >    78 |         let container = unsafe { &*((*param).__bindgen_anon_1.arg.cast::<SetOnce<T>>()) };
> >    |                                              ^^^^^^^^^^^^^^^^ unknown field
> >    |
> >    = note: available field is: `_address`
> > 
> 
> I can't replicate this issue either.
> 
> I've added these patches to fix other unrelated build issues, so, I'm not sure
> how 0day ended up skipping them? Perhaps it uses head 95cb2fd6c? + bisect?
> 
> a74b6c0e53a6d um: Don't rename vmap to kernel_vmap
> f74cf399e02e2 rust: debugfs: Replace the usage of Rust native atomics 
> 013f912eb5fa7 rust: sync: atomic: Implement Debug for Atomic<Debug> 
> 14e9a18b07ec4 rust: sync: atomic: Make Atomic*Ops pub(crate)
> 
> My testing branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/da.gomez/linux.git/log/?h=20251202-0day-test-0b08fc292842-with-fixes
> 
> FWIW, this is what I've tried:
> 
> rustc --version --verbose
> rustc 1.88.0 (6b00bc388 2025-06-23)
> binary: rustc
> commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
> commit-date: 2025-06-23
> host: x86_64-unknown-linux-gnu
> release: 1.88.0
> LLVM version: 20.1.5
> 
> bindgen --version --verbose
> bindgen 0.72.1

sorry for false positive. we confirmed this is an issue caused by a bug in
bindgen - https://github.com/rust-lang/rust-bindgen/issues/3264

we used 0.72.0 when saw the issues. now we upgraded to 0.72.1 as you used, now
issue disappears.


> Clang: Debian clang version 21.1.5 (1)
> 
> rm -rfv build_dir/
> mkdir -p build_dir/
> wget https://download.01.org/0day-ci/archive/20251202/202512020454.Tf36WHw5-lkp@intel.com/config -O build_dir/.config
> 
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang-22 ~/lkp-tests/kbuild/make.cross W=1 O=build_dir ARCH=arm64 rustavailable
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang-22 ~/lkp-tests/kbuild/make.cross W=1 O=build_dir ARCH=arm64 olddefconfig
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang-22 ~/lkp-tests/kbuild/make.cross W=1 O=build_dir ARCH=arm64 prepare
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang-22 ~/lkp-tests/kbuild/make.cross W=1 O=build_dir ARCH=arm64 -j$(nproc)
> 
> grep -i "bindgen\|rustc\|llv\|clang" build_dir/.config
> CONFIG_CC_VERSION_TEXT="ClangBuiltLinux clang version 22.0.0git (https://github.com/llvm/llvm-project.git e19fa930ca838715028c00c234874d1db4f93154)"
> CONFIG_CC_IS_CLANG=y
> CONFIG_CLANG_VERSION=220000
> CONFIG_AS_IS_LLVM=y
> CONFIG_RUSTC_VERSION=108800
> CONFIG_RUSTC_LLVM_VERSION=200105
> CONFIG_RUSTC_HAS_COERCE_POINTEE=y
> CONFIG_RUSTC_HAS_SPAN_FILE=y
> CONFIG_RUSTC_HAS_UNNECESSARY_TRANSMUTES=y
> CONFIG_RUSTC_VERSION_TEXT="rustc 1.88.0 (6b00bc388 2025-06-23)"
> CONFIG_BINDGEN_VERSION_TEXT="bindgen 0.72.1"
> CONFIG_RUSTC_SUPPORTS_ARM64=y
> CONFIG_CLANG_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS=y
> CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
> CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
> CONFIG_HAS_LTO_CLANG=y
> # CONFIG_LTO_CLANG_THIN is not set
> CONFIG_HAVE_CFI_ICALL_NORMALIZE_INTEGERS_RUSTC=y
> 
> Build succeeds without issues (warnings, yes).
> 

Re: [linux-next:master 4752/13171] error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`

[Andreas Hindborg]

Hi Oliver,

"Oliver Sang" <oliver.sang@intel.com> writes:

> hi, Daniel Gomez,
>
> On Tue, Dec 02, 2025 at 10:02:02PM +0100, Daniel Gomez wrote:
>>
>>
>> On 01/12/2025 21.20, kernel test robot wrote:
>> > Hi Andreas,
>> >
>> > FYI, the error/warning still remains.
>> >
>> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>> > head:   95cb2fd6ce0ad61af54191fe5ef271d7177f9c3a
>> > commit: 0b08fc292842a13aa496413b48c1efb83573b8c6 [4752/13171] rust: introduce module_param module
>> > config: arm64-randconfig-001-20251202 (https://download.01.org/0day-ci/archive/20251202/202512020454.Tf36WHw5-lkp@intel.com/config)
>> > compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project b3428bb966f1de8aa48375ffee0eba04ede133b7)
>> > rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
>> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251202/202512020454.Tf36WHw5-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/202512020454.Tf36WHw5-lkp@intel.com/
>> >
>> > All errors (new ones prefixed by >>):
>> >
>> >>> error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`
>> >    --> rust/kernel/module_param.rs:78:46
>> >    |
>> >    78 |         let container = unsafe { &*((*param).__bindgen_anon_1.arg.cast::<SetOnce<T>>()) };
>> >    |                                              ^^^^^^^^^^^^^^^^ unknown field
>> >    |
>> >    = note: available field is: `_address`
>> >
>>
>> I can't replicate this issue either.
>>
>> I've added these patches to fix other unrelated build issues, so, I'm not sure
>> how 0day ended up skipping them? Perhaps it uses head 95cb2fd6c? + bisect?
>>
>> a74b6c0e53a6d um: Don't rename vmap to kernel_vmap
>> f74cf399e02e2 rust: debugfs: Replace the usage of Rust native atomics
>> 013f912eb5fa7 rust: sync: atomic: Implement Debug for Atomic<Debug>
>> 14e9a18b07ec4 rust: sync: atomic: Make Atomic*Ops pub(crate)
>>
>> My testing branch:
>> https://git.kernel.org/pub/scm/linux/kernel/git/da.gomez/linux.git/log/?h=20251202-0day-test-0b08fc292842-with-fixes
>>
>> FWIW, this is what I've tried:
>>
>> rustc --version --verbose
>> rustc 1.88.0 (6b00bc388 2025-06-23)
>> binary: rustc
>> commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
>> commit-date: 2025-06-23
>> host: x86_64-unknown-linux-gnu
>> release: 1.88.0
>> LLVM version: 20.1.5
>>
>> bindgen --version --verbose
>> bindgen 0.72.1
>
> sorry for false positive. we confirmed this is an issue caused by a bug in
> bindgen - https://github.com/rust-lang/rust-bindgen/issues/3264
>
> we used 0.72.0 when saw the issues. now we upgraded to 0.72.1 as you used, now
> issue disappears.

Thanks for confirming!

While we could see from the config that you were using bindgen 0.72.0,
it was not clear to us where you get this bindgen from. Obtaining
bindgen does not seem to be part of the reproducer instructions (or
maybe I am not looking in the right place?).

If I understand correctly, this issue manifested only when building
bindgen 0.72.0 with clang-22-git. Building this was next on our list in
trying to reproduce, but getting to that conclusion took a while.

Anyway, I want to ask if you can include directions for obtaining or
building bindgen in your reproducer instructions?

Best regards,
Andreas Hindborg

Re: [linux-next:master 4752/13171] error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`

[Daniel Gomez]

On 04/12/2025 12.47, Andreas Hindborg wrote:
> Hi Oliver,
> 
> "Oliver Sang" <oliver.sang@intel.com> writes:
> 
>> hi, Daniel Gomez,
>>
>> On Tue, Dec 02, 2025 at 10:02:02PM +0100, Daniel Gomez wrote:
>>>
>>>
>>> On 01/12/2025 21.20, kernel test robot wrote:
>>>> Hi Andreas,
>>>>
>>>> FYI, the error/warning still remains.
>>>>
>>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>>>> head:   95cb2fd6ce0ad61af54191fe5ef271d7177f9c3a
>>>> commit: 0b08fc292842a13aa496413b48c1efb83573b8c6 [4752/13171] rust: introduce module_param module
>>>> config: arm64-randconfig-001-20251202 (https://download.01.org/0day-ci/archive/20251202/202512020454.Tf36WHw5-lkp@intel.com/config)
>>>> compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project b3428bb966f1de8aa48375ffee0eba04ede133b7)
>>>> rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
>>>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251202/202512020454.Tf36WHw5-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/202512020454.Tf36WHw5-lkp@intel.com/
>>>>
>>>> All errors (new ones prefixed by >>):
>>>>
>>>>>> error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`
>>>>    --> rust/kernel/module_param.rs:78:46
>>>>    |
>>>>    78 |         let container = unsafe { &*((*param).__bindgen_anon_1.arg.cast::<SetOnce<T>>()) };
>>>>    |                                              ^^^^^^^^^^^^^^^^ unknown field
>>>>    |
>>>>    = note: available field is: `_address`
>>>>
>>>
>>> I can't replicate this issue either.
>>>
>>> I've added these patches to fix other unrelated build issues, so, I'm not sure
>>> how 0day ended up skipping them? Perhaps it uses head 95cb2fd6c? + bisect?
>>>
>>> a74b6c0e53a6d um: Don't rename vmap to kernel_vmap
>>> f74cf399e02e2 rust: debugfs: Replace the usage of Rust native atomics
>>> 013f912eb5fa7 rust: sync: atomic: Implement Debug for Atomic<Debug>
>>> 14e9a18b07ec4 rust: sync: atomic: Make Atomic*Ops pub(crate)
>>>
>>> My testing branch:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/da.gomez/linux.git/log/?h=20251202-0day-test-0b08fc292842-with-fixes
>>>
>>> FWIW, this is what I've tried:
>>>
>>> rustc --version --verbose
>>> rustc 1.88.0 (6b00bc388 2025-06-23)
>>> binary: rustc
>>> commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
>>> commit-date: 2025-06-23
>>> host: x86_64-unknown-linux-gnu
>>> release: 1.88.0
>>> LLVM version: 20.1.5
>>>
>>> bindgen --version --verbose
>>> bindgen 0.72.1
>>
>> sorry for false positive. we confirmed this is an issue caused by a bug in
>> bindgen - https://github.com/rust-lang/rust-bindgen/issues/3264
>>
>> we used 0.72.0 when saw the issues. now we upgraded to 0.72.1 as you used, now
>> issue disappears.
> 
> Thanks for confirming!

Thanks Oliver!

> 
> While we could see from the config that you were using bindgen 0.72.0,
> it was not clear to us where you get this bindgen from. Obtaining
> bindgen does not seem to be part of the reproducer instructions (or
> maybe I am not looking in the right place?).
> 
> If I understand correctly, this issue manifested only when building
> bindgen 0.72.0 with clang-22-git. Building this was next on our list in
> trying to reproduce, but getting to that conclusion took a while.
> 
> Anyway, I want to ask if you can include directions for obtaining or
> building bindgen in your reproducer instructions?

+ Any reason to use an unreleased clang version for this reports? Since clang-22
is not officially released yet, issues seen with it seem lower priority than
those reproduced with stable, released versions. Does it make sense to act
on these kind of "bleeding edge" reports, or should we wait until they're
confirmed on a stable release? Does 0day test both?

> 
> Best regards,
> Andreas Hindborg
> 

Re: [linux-next:master 4752/13171] error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`

[Miguel Ojeda]

On Thu, Dec 4, 2025 at 12:59 PM Daniel Gomez <da.gomez@kernel.org> wrote:
>
> + Any reason to use an unreleased clang version for this reports? Since clang-22
> is not officially released yet, issues seen with it seem lower priority than
> those reproduced with stable, released versions. Does it make sense to act
> on these kind of "bleeding edge" reports, or should we wait until they're
> confirmed on a stable release? Does 0day test both?

Some people in the kernel regularly test with unreleased compilers
(all GCC, Clang and Rust) in order to fix issues before those
compilers get actually released, e.g. ClangBuiltLinux for LLVM, I do
it for `rustc`, several people for GCC, etc.

So I guess the idea is similar for kernel test robot? There is value
on doing that, and whether one should act depends -- if it is close to
the release of the compiler, then it makes sense to try to figure out
what is breaking so that the compiler has a chance to fix it.
Otherwise, if nobody tries, we would get quite broken compilers (for
the kernel use case at least).

It is also why I think having at least a basic kernel build on the
upstream CIs of the compilers is a good idea (it already showed value
in upstream Rust and perhaps we should talk about it again in LPC for
Clang).

But, yeah, the reports can be confusing and reacting to them properly
does take time and effort (e.g. I need sometimes to bisect the
compiler etc.).

Does LKP try the bleeding edge versions only if a stable compiler
built successfully? That could perhaps help.

Andreas also suggested yesterday in our meeting to have such bleeding
edge reports perhaps more clearly marked or similar.

Cheers,
Miguel

Re: [linux-next:master 4752/13171] error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`

[Philip Li]

On Thu, Dec 04, 2025 at 12:59:02PM +0100, Daniel Gomez wrote:
> > While we could see from the config that you were using bindgen 0.72.0,
> > it was not clear to us where you get this bindgen from. Obtaining
> > bindgen does not seem to be part of the reproducer instructions (or
> > maybe I am not looking in the right place?).
> > 
> > If I understand correctly, this issue manifested only when building
> > bindgen 0.72.0 with clang-22-git. Building this was next on our list in
> > trying to reproduce, but getting to that conclusion took a while.
> > 
> > Anyway, I want to ask if you can include directions for obtaining or
> > building bindgen in your reproducer instructions?
> 
> + Any reason to use an unreleased clang version for this reports? Since clang-22
> is not officially released yet, issues seen with it seem lower priority than
> those reproduced with stable, released versions. Does it make sense to act
> on these kind of "bleeding edge" reports, or should we wait until they're
> confirmed on a stable release? Does 0day test both?

Hi Andreas, currently the bot will test multiple versions of clang including released
ones like clang-20/clang-21, plus the latest clang from its repo.

We do have some patterns to send reports of low confidence to llvm@lists only or to
have manual check before sending out, probably we can also add some guard when rust
issue is reported on unreleased clang?

> 
> > 
> > Best regards,
> > Andreas Hindborg
> > 
> 

Re: [linux-next:master 4752/13171] error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`

[Philip Li]

On Thu, Dec 04, 2025 at 01:24:03PM +0100, Miguel Ojeda wrote:
> On Thu, Dec 4, 2025 at 12:59 PM Daniel Gomez <da.gomez@kernel.org> wrote:
> >
> > + Any reason to use an unreleased clang version for this reports? Since clang-22
> > is not officially released yet, issues seen with it seem lower priority than
> > those reproduced with stable, released versions. Does it make sense to act
> > on these kind of "bleeding edge" reports, or should we wait until they're
> > confirmed on a stable release? Does 0day test both?
> 
> Some people in the kernel regularly test with unreleased compilers
> (all GCC, Clang and Rust) in order to fix issues before those
> compilers get actually released, e.g. ClangBuiltLinux for LLVM, I do
> it for `rustc`, several people for GCC, etc.
> 
> So I guess the idea is similar for kernel test robot? There is value
> on doing that, and whether one should act depends -- if it is close to
> the release of the compiler, then it makes sense to try to figure out
> what is breaking so that the compiler has a chance to fix it.
> Otherwise, if nobody tries, we would get quite broken compilers (for
> the kernel use case at least).

thanks, the bot tests multiple versions of compiler for both gcc and clang.
For clang, low confidence ones will only be sent to llvm mailing list for
check firstly, and for other issues, we will cc llvm mailing list who also
monitor this closely and help check in case there's issue in latest compiler.

> 
> It is also why I think having at least a basic kernel build on the
> upstream CIs of the compilers is a good idea (it already showed value
> in upstream Rust and perhaps we should talk about it again in LPC for
> Clang).
> 
> But, yeah, the reports can be confusing and reacting to them properly
> does take time and effort (e.g. I need sometimes to bisect the
> compiler etc.).
> 
> Does LKP try the bleeding edge versions only if a stable compiler
> built successfully? That could perhaps help.

For bleeding edge, the bot regularly builds and use latest code now.

> 
> Andreas also suggested yesterday in our meeting to have such bleeding
> edge reports perhaps more clearly marked or similar.

Probably we can mark rust issue as low confidence when it occurs on non
released compiler, so it will not be directly sent to developer before it
is further checked?

> 
> Cheers,
> Miguel
> 

Re: [linux-next:master 4752/13171] error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`

[Oliver Sang]

hi, Andreas Hindborg,

On Thu, Dec 04, 2025 at 12:47:05PM +0100, Andreas Hindborg wrote:
> Hi Oliver,
> 
> >
> > we used 0.72.0 when saw the issues. now we upgraded to 0.72.1 as you used, now
> > issue disappears.
> 
> Thanks for confirming!
> 
> While we could see from the config that you were using bindgen 0.72.0,
> it was not clear to us where you get this bindgen from. Obtaining
> bindgen does not seem to be part of the reproducer instructions (or
> maybe I am not looking in the right place?).

right, for rust, we don't supply instructions how to setup rust env for now.
sorry for inconvenience.

> 
> If I understand correctly, this issue manifested only when building
> bindgen 0.72.0 with clang-22-git. Building this was next on our list in
> trying to reproduce, but getting to that conclusion took a while.
> 
> Anyway, I want to ask if you can include directions for obtaining or
> building bindgen in your reproducer instructions?

hi, Philip, can we do this?

> 
> Best regards,
> Andreas Hindborg
> 

Re: [linux-next:master 4752/13171] error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`

[Philip Li]

On Fri, Dec 05, 2025 at 10:19:02AM +0800, Oliver Sang wrote:
> hi, Andreas Hindborg,
> 
> On Thu, Dec 04, 2025 at 12:47:05PM +0100, Andreas Hindborg wrote:
> > Hi Oliver,
> > 
> > >
> > > we used 0.72.0 when saw the issues. now we upgraded to 0.72.1 as you used, now
> > > issue disappears.
> > 
> > Thanks for confirming!
> > 
> > While we could see from the config that you were using bindgen 0.72.0,
> > it was not clear to us where you get this bindgen from. Obtaining
> > bindgen does not seem to be part of the reproducer instructions (or
> > maybe I am not looking in the right place?).
> 
> right, for rust, we don't supply instructions how to setup rust env for now.
> sorry for inconvenience.
> 
> > 
> > If I understand correctly, this issue manifested only when building
> > bindgen 0.72.0 with clang-22-git. Building this was next on our list in
> > trying to reproduce, but getting to that conclusion took a while.
> > 
> > Anyway, I want to ask if you can include directions for obtaining or
> > building bindgen in your reproducer instructions?
> 
> hi, Philip, can we do this?

yes, let me add this earlier next week to provide extra instructions
for rust build.

> 
> > 
> > Best regards,
> > Andreas Hindborg
> > 

Re: [linux-next:master 4752/13171] error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`

[Andreas Hindborg]

"Philip Li" <philip.li@intel.com> writes:

> On Thu, Dec 04, 2025 at 01:24:03PM +0100, Miguel Ojeda wrote:
>> On Thu, Dec 4, 2025 at 12:59 PM Daniel Gomez <da.gomez@kernel.org> wrote:
>> >
>> > + Any reason to use an unreleased clang version for this reports? Since clang-22
>> > is not officially released yet, issues seen with it seem lower priority than
>> > those reproduced with stable, released versions. Does it make sense to act
>> > on these kind of "bleeding edge" reports, or should we wait until they're
>> > confirmed on a stable release? Does 0day test both?
>>
>> Some people in the kernel regularly test with unreleased compilers
>> (all GCC, Clang and Rust) in order to fix issues before those
>> compilers get actually released, e.g. ClangBuiltLinux for LLVM, I do
>> it for `rustc`, several people for GCC, etc.
>>
>> So I guess the idea is similar for kernel test robot? There is value
>> on doing that, and whether one should act depends -- if it is close to
>> the release of the compiler, then it makes sense to try to figure out
>> what is breaking so that the compiler has a chance to fix it.
>> Otherwise, if nobody tries, we would get quite broken compilers (for
>> the kernel use case at least).
>
> thanks, the bot tests multiple versions of compiler for both gcc and clang.
> For clang, low confidence ones will only be sent to llvm mailing list for
> check firstly, and for other issues, we will cc llvm mailing list who also
> monitor this closely and help check in case there's issue in latest compiler.
>
>>
>> It is also why I think having at least a basic kernel build on the
>> upstream CIs of the compilers is a good idea (it already showed value
>> in upstream Rust and perhaps we should talk about it again in LPC for
>> Clang).
>>
>> But, yeah, the reports can be confusing and reacting to them properly
>> does take time and effort (e.g. I need sometimes to bisect the
>> compiler etc.).
>>
>> Does LKP try the bleeding edge versions only if a stable compiler
>> built successfully? That could perhaps help.
>
> For bleeding edge, the bot regularly builds and use latest code now.
>
>>
>> Andreas also suggested yesterday in our meeting to have such bleeding
>> edge reports perhaps more clearly marked or similar.
>
> Probably we can mark rust issue as low confidence when it occurs on non
> released compiler, so it will not be directly sent to developer before it
> is further checked?

Would it be possible to still send the report, but to inject a line to
the report stating it is marked as low confidence due to X and Y
(unreleased compiler etc.)?

I think it is still valuable to get the reports, but it would be nice to
know we don't need to scramble all hands on deck immediately.

I guess one could also just read the report more carefully to learn
that an unreleased compiler was used. But seeing this at a glance would
be great.


Best regards,
Andreas Hindborg

Re: [linux-next:master 4752/13171] error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`

[Philip Li]

On Fri, Dec 05, 2025 at 11:43:21AM +0100, Andreas Hindborg wrote:
> "Philip Li" <philip.li@intel.com> writes:
> 
> > On Thu, Dec 04, 2025 at 01:24:03PM +0100, Miguel Ojeda wrote:
> >> On Thu, Dec 4, 2025 at 12:59 PM Daniel Gomez <da.gomez@kernel.org> wrote:
> >> >
> >> > + Any reason to use an unreleased clang version for this reports? Since clang-22
> >> > is not officially released yet, issues seen with it seem lower priority than
> >> > those reproduced with stable, released versions. Does it make sense to act
> >> > on these kind of "bleeding edge" reports, or should we wait until they're
> >> > confirmed on a stable release? Does 0day test both?
> >>
> >> Some people in the kernel regularly test with unreleased compilers
> >> (all GCC, Clang and Rust) in order to fix issues before those
> >> compilers get actually released, e.g. ClangBuiltLinux for LLVM, I do
> >> it for `rustc`, several people for GCC, etc.
> >>
> >> So I guess the idea is similar for kernel test robot? There is value
> >> on doing that, and whether one should act depends -- if it is close to
> >> the release of the compiler, then it makes sense to try to figure out
> >> what is breaking so that the compiler has a chance to fix it.
> >> Otherwise, if nobody tries, we would get quite broken compilers (for
> >> the kernel use case at least).
> >
> > thanks, the bot tests multiple versions of compiler for both gcc and clang.
> > For clang, low confidence ones will only be sent to llvm mailing list for
> > check firstly, and for other issues, we will cc llvm mailing list who also
> > monitor this closely and help check in case there's issue in latest compiler.
> >
> >>
> >> It is also why I think having at least a basic kernel build on the
> >> upstream CIs of the compilers is a good idea (it already showed value
> >> in upstream Rust and perhaps we should talk about it again in LPC for
> >> Clang).
> >>
> >> But, yeah, the reports can be confusing and reacting to them properly
> >> does take time and effort (e.g. I need sometimes to bisect the
> >> compiler etc.).
> >>
> >> Does LKP try the bleeding edge versions only if a stable compiler
> >> built successfully? That could perhaps help.
> >
> > For bleeding edge, the bot regularly builds and use latest code now.
> >
> >>
> >> Andreas also suggested yesterday in our meeting to have such bleeding
> >> edge reports perhaps more clearly marked or similar.
> >
> > Probably we can mark rust issue as low confidence when it occurs on non
> > released compiler, so it will not be directly sent to developer before it
> > is further checked?
> 
> Would it be possible to still send the report, but to inject a line to
> the report stating it is marked as low confidence due to X and Y
> (unreleased compiler etc.)?

Got it, i can add a new line or update the reproduce line from

	reproduce (this is a W=1 build):

To

	reproduce (this is a W=1 build on unreleased compiler):

I can wait for a while to see any other comments regarding this. And
of course, this can be refined at any time in the future to make the
report clear.

> 
> I think it is still valuable to get the reports, but it would be nice to
> know we don't need to scramble all hands on deck immediately.

Got it, sorry for this time's unclear info.

> 
> I guess one could also just read the report more carefully to learn
> that an unreleased compiler was used. But seeing this at a glance would
> be great.
> 
> 
> Best regards,
> Andreas Hindborg
> 
>