[linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head:   88cbd8ac379cf5ce68b7efcfd4d1484a6871ee0b
commit: 01e345e82ec3a5a7edeb9fa0dcb7fd4b0e5c534e [9676/10599] rust: num: add Bounded integer wrapping type
config: loongarch-randconfig-6002-20251120 (https://download.01.org/0day-ci/archive/20251121/202511210055.RUsFNku1-lkp@intel.com/config)
compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251121/202511210055.RUsFNku1-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/202511210055.RUsFNku1-lkp@intel.com/

All errors (new ones prefixed by >>):

>> ld.lld: error: undefined symbol: rust_build_error
   >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
   >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u8, 1>>::from_expr) in archive vmlinux.a
   >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
   >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u32, 4>>::from_expr) in archive vmlinux.a
   >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
   >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u16, 8>>::from_expr) in archive vmlinux.a

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

Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Alexandre Courbot]

On Fri Nov 21, 2025 at 1:41 AM JST, kernel test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head:   88cbd8ac379cf5ce68b7efcfd4d1484a6871ee0b
> commit: 01e345e82ec3a5a7edeb9fa0dcb7fd4b0e5c534e [9676/10599] rust: num: add Bounded integer wrapping type
> config: loongarch-randconfig-6002-20251120 (https://download.01.org/0day-ci/archive/20251121/202511210055.RUsFNku1-lkp@intel.com/config)
> compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
> rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251121/202511210055.RUsFNku1-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/202511210055.RUsFNku1-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
>>> ld.lld: error: undefined symbol: rust_build_error
>    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
>    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u8, 1>>::from_expr) in archive vmlinux.a
>    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
>    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u32, 4>>::from_expr) in archive vmlinux.a
>    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
>    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u16, 8>>::from_expr) in archive vmlinux.a

Mmm, I don't like this. The expressions that are failing are extremely
simple, for instance:

    Bounded::<u8, 1>::from_expr(1)

So if the compiler is unable to assess that this won't fail, this might
be a deal-breaker for `from_expr` and we might need to remove it. :(

This would also mean a lot more runtime checks when working with
bitfields and registers. Or can we assume that this is a compiler
problem on this particular architecture?

Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Alice Ryhl]

On Fri, Nov 21, 2025 at 03:13:16PM +0900, Alexandre Courbot wrote:
> On Fri Nov 21, 2025 at 1:41 AM JST, kernel test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > head:   88cbd8ac379cf5ce68b7efcfd4d1484a6871ee0b
> > commit: 01e345e82ec3a5a7edeb9fa0dcb7fd4b0e5c534e [9676/10599] rust: num: add Bounded integer wrapping type
> > config: loongarch-randconfig-6002-20251120 (https://download.01.org/0day-ci/archive/20251121/202511210055.RUsFNku1-lkp@intel.com/config)
> > compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
> > rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251121/202511210055.RUsFNku1-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/202511210055.RUsFNku1-lkp@intel.com/
> >
> > All errors (new ones prefixed by >>):
> >
> >>> ld.lld: error: undefined symbol: rust_build_error
> >    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
> >    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u8, 1>>::from_expr) in archive vmlinux.a
> >    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
> >    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u32, 4>>::from_expr) in archive vmlinux.a
> >    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
> >    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u16, 8>>::from_expr) in archive vmlinux.a
> 
> Mmm, I don't like this. The expressions that are failing are extremely
> simple, for instance:
> 
>     Bounded::<u8, 1>::from_expr(1)
> 
> So if the compiler is unable to assess that this won't fail, this might
> be a deal-breaker for `from_expr` and we might need to remove it. :(
> 
> This would also mean a lot more runtime checks when working with
> bitfields and registers. Or can we assume that this is a compiler
> problem on this particular architecture?

Yeah, it sounds like from_expr() isn't going to work.

Alice

Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Alexandre Courbot]

On Fri Nov 21, 2025 at 6:08 PM JST, Alice Ryhl wrote:
> On Fri, Nov 21, 2025 at 03:13:16PM +0900, Alexandre Courbot wrote:
>> On Fri Nov 21, 2025 at 1:41 AM JST, kernel test robot wrote:
>> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>> > head:   88cbd8ac379cf5ce68b7efcfd4d1484a6871ee0b
>> > commit: 01e345e82ec3a5a7edeb9fa0dcb7fd4b0e5c534e [9676/10599] rust: num: add Bounded integer wrapping type
>> > config: loongarch-randconfig-6002-20251120 (https://download.01.org/0day-ci/archive/20251121/202511210055.RUsFNku1-lkp@intel.com/config)
>> > compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
>> > rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
>> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251121/202511210055.RUsFNku1-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/202511210055.RUsFNku1-lkp@intel.com/
>> >
>> > All errors (new ones prefixed by >>):
>> >
>> >>> ld.lld: error: undefined symbol: rust_build_error
>> >    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
>> >    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u8, 1>>::from_expr) in archive vmlinux.a
>> >    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
>> >    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u32, 4>>::from_expr) in archive vmlinux.a
>> >    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
>> >    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u16, 8>>::from_expr) in archive vmlinux.a
>> 
>> Mmm, I don't like this. The expressions that are failing are extremely
>> simple, for instance:
>> 
>>     Bounded::<u8, 1>::from_expr(1)
>> 
>> So if the compiler is unable to assess that this won't fail, this might
>> be a deal-breaker for `from_expr` and we might need to remove it. :(
>> 
>> This would also mean a lot more runtime checks when working with
>> bitfields and registers. Or can we assume that this is a compiler
>> problem on this particular architecture?
>
> Yeah, it sounds like from_expr() isn't going to work.

It would be a pity but we can replace `from_expr` with an unsafe
`new_unchecked` for these cases where the caller is absolutely sure of
their input. I have tried on bitfield/Nova and the result is not too
bad.

Still, this is a bummer - it is much better to have the compiler
validate safety properties than relying on a SAFETY comment.

I notice that loongarch is a Tier 2 Rust platform, but I suppose that's
not an excuse to let it not build? ^_^;

If I had to bet I'd wager that in this case the "shift left then back
right" technique to check the bounds is not working well. I will try to
find an alternative, but meanwhile we should probably remove
`from_expr`. I will send a patch to that effect unless told otherwise.

Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Alice Ryhl]

On Fri, Nov 21, 2025 at 10:41:46PM +0900, Alexandre Courbot wrote:
> On Fri Nov 21, 2025 at 6:08 PM JST, Alice Ryhl wrote:
> > On Fri, Nov 21, 2025 at 03:13:16PM +0900, Alexandre Courbot wrote:
> >> On Fri Nov 21, 2025 at 1:41 AM JST, kernel test robot wrote:
> >> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> >> > head:   88cbd8ac379cf5ce68b7efcfd4d1484a6871ee0b
> >> > commit: 01e345e82ec3a5a7edeb9fa0dcb7fd4b0e5c534e [9676/10599] rust: num: add Bounded integer wrapping type
> >> > config: loongarch-randconfig-6002-20251120 (https://download.01.org/0day-ci/archive/20251121/202511210055.RUsFNku1-lkp@intel.com/config)
> >> > compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
> >> > rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
> >> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251121/202511210055.RUsFNku1-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/202511210055.RUsFNku1-lkp@intel.com/
> >> >
> >> > All errors (new ones prefixed by >>):
> >> >
> >> >>> ld.lld: error: undefined symbol: rust_build_error
> >> >    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
> >> >    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u8, 1>>::from_expr) in archive vmlinux.a
> >> >    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
> >> >    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u32, 4>>::from_expr) in archive vmlinux.a
> >> >    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
> >> >    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u16, 8>>::from_expr) in archive vmlinux.a
> >> 
> >> Mmm, I don't like this. The expressions that are failing are extremely
> >> simple, for instance:
> >> 
> >>     Bounded::<u8, 1>::from_expr(1)
> >> 
> >> So if the compiler is unable to assess that this won't fail, this might
> >> be a deal-breaker for `from_expr` and we might need to remove it. :(
> >> 
> >> This would also mean a lot more runtime checks when working with
> >> bitfields and registers. Or can we assume that this is a compiler
> >> problem on this particular architecture?
> >
> > Yeah, it sounds like from_expr() isn't going to work.
> 
> It would be a pity but we can replace `from_expr` with an unsafe
> `new_unchecked` for these cases where the caller is absolutely sure of
> their input. I have tried on bitfield/Nova and the result is not too
> bad.
> 
> Still, this is a bummer - it is much better to have the compiler
> validate safety properties than relying on a SAFETY comment.

This kind of thing is why I keep saying build_error() is too fragile to
be used at all.

> I notice that loongarch is a Tier 2 Rust platform, but I suppose that's
> not an excuse to let it not build? ^_^;

What Tier upstream Rust uses for the target is irrelevant for us IMO.

Or at least, it may be relevant in the "add this target to Linux?"
discussion. But once we added it, it's not relevant anymore.

> If I had to bet I'd wager that in this case the "shift left then back
> right" technique to check the bounds is not working well. I will try to
> find an alternative, but meanwhile we should probably remove
> `from_expr`. I will send a patch to that effect unless told otherwise.

Alice

Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Miguel Ojeda]

On Fri, Nov 21, 2025 at 3:10 PM Alice Ryhl <aliceryhl@google.com> wrote:
>
> This kind of thing is why I keep saying build_error() is too fragile to
> be used at all.

Adding `unsafe` blocks for things that should be able to be statically
known isn't great.

`build_assert!` is just too useful, so it is best to try to understand
what can be done, or find an equivalent solution. Gary et al. may have
some input here.

Perhaps we need to resort to a macro, that would at least be better
than adding `unsafe` blocks. It is what C does in many cases, after
all.

Cheers,
Miguel

Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Gary Guo]

On Fri, 21 Nov 2025 15:21:45 +0100
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:

> On Fri, Nov 21, 2025 at 3:10 PM Alice Ryhl <aliceryhl@google.com> wrote:
> >
> > This kind of thing is why I keep saying build_error() is too fragile to
> > be used at all.  

The case here I think is a perfectly fine use case of `build_error` as
it's completely by-value and does involve references. If compiler can't
figure out, it's either a compiler bug or a source bug.

> Adding `unsafe` blocks for things that should be able to be statically
> known isn't great.
> 
> `build_assert!` is just too useful, so it is best to try to understand
> what can be done, or find an equivalent solution. Gary et al. may have
> some input here.

I'd argue that these build issues actually helps us catch missed
optimisations opportunities :)

For this particular issue, I noticed that none of the functions
involved here (`from_expr` and `fits_within`) are marked as `#[inline]`.
I suspect after marking them as inline this case should be resolved.

Best,
Gary

Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Alexandre Courbot]

On Fri Nov 21, 2025 at 11:30 PM JST, Gary Guo wrote:
> On Fri, 21 Nov 2025 15:21:45 +0100
> Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>
>> On Fri, Nov 21, 2025 at 3:10 PM Alice Ryhl <aliceryhl@google.com> wrote:
>> >
>> > This kind of thing is why I keep saying build_error() is too fragile to
>> > be used at all.  
>
> The case here I think is a perfectly fine use case of `build_error` as
> it's completely by-value and does involve references. If compiler can't
> figure out, it's either a compiler bug or a source bug.
>
>> Adding `unsafe` blocks for things that should be able to be statically
>> known isn't great.
>> 
>> `build_assert!` is just too useful, so it is best to try to understand
>> what can be done, or find an equivalent solution. Gary et al. may have
>> some input here.
>
> I'd argue that these build issues actually helps us catch missed
> optimisations opportunities :)
>
> For this particular issue, I noticed that none of the functions
> involved here (`from_expr` and `fits_within`) are marked as `#[inline]`.
> I suspect after marking them as inline this case should be resolved.

Indeed. Another thing that caught my attention is that the `num_bits`
parameter of `fits_within` could be turned into a const generic.

Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Alice Ryhl]

On Fri, Nov 21, 2025 at 02:30:08PM +0000, Gary Guo wrote:
> On Fri, 21 Nov 2025 15:21:45 +0100
> Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> 
> > On Fri, Nov 21, 2025 at 3:10 PM Alice Ryhl <aliceryhl@google.com> wrote:
> > >
> > > This kind of thing is why I keep saying build_error() is too fragile to
> > > be used at all.  
> 
> The case here I think is a perfectly fine use case of `build_error` as
> it's completely by-value and does involve references. If compiler can't
> figure out, it's either a compiler bug or a source bug.

The thing about this particular case is that it should have been

	const { Bounded::<u8, 1>::from_expr(1) }

or similar.

You say that this kind of thing would be a compiler bug, but I don't
think the compiler devs folks would agree with us on that at all. I
mean, sure, it's a bug in the sense that it's a missed optimization, but
it's not a correctness bug.

If we used const eval, then suddenly it *would* easily be a compiler
bug, and by the way, it would also work reliably.

> > Adding `unsafe` blocks for things that should be able to be statically
> > known isn't great.
> > 
> > `build_assert!` is just too useful, so it is best to try to understand
> > what can be done, or find an equivalent solution. Gary et al. may have
> > some input here.

I'm not advocating for adding unsafe blocks to skip bounds checks.

And, fine, there are probably a few cases where it works reliably and
has no real replacement. Such as the VTABLE_DEFAULT_ERROR check. But I
do not think bounds checks are a place where it's a good idea.

Alice

Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Miguel Ojeda]

On Fri, Nov 21, 2025 at 3:44 PM Alice Ryhl <aliceryhl@google.com> wrote:
>
> You say that this kind of thing would be a compiler bug, but I don't
> think the compiler devs folks would agree with us on that at all. I
> mean, sure, it's a bug in the sense that it's a missed optimization, but
> it's not a correctness bug.

> I'm not advocating for adding unsafe blocks to skip bounds checks.
>
> And, fine, there are probably a few cases where it works reliably and
> has no real replacement. Such as the VTABLE_DEFAULT_ERROR check. But I
> do not think bounds checks are a place where it's a good idea.

There may be no guarantees, but it is a similar situation as for C
compilers in the kernel.

Compilers can of course change behavior and have bugs and so on, and
thus avoiding to rely on it as much as possible is a good idea, but I
think it is a good idea to get build asserts reliably working as much
as possible for certain use cases. In particular, I don't see why
simple (local-enough) bounds checks cannot be one of those (it may not
be today, but it could).

Of course, the best would be to get the language to a point where it
supports this sort of thing natively. But that is a longer road.

And, in some situations, there may be no good alternative (i.e. const
eval / generics / macros may be too painful to apply), and thus people
may end up adding `unsafe` instead, which isn't great.

In addition, I think upstream probably wants to know about this sort
of this, i.e. sometimes the changes may be unintended (i.e. if we see
it changing in a new nightly) and they probably like to hear about
"obvious" optimizations not being applied, since they are potential
easy wins for them (or, rather, avoiding regressions), as Gary
mentions. That is also part of the value of building the kernel in
compiler CIs etc.

Cheers,
Miguel

Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Alice Ryhl]

On Fri, Nov 21, 2025 at 04:53:26PM +0100, Miguel Ojeda wrote:
> On Fri, Nov 21, 2025 at 3:44 PM Alice Ryhl <aliceryhl@google.com> wrote:
> >
> > You say that this kind of thing would be a compiler bug, but I don't
> > think the compiler devs folks would agree with us on that at all. I
> > mean, sure, it's a bug in the sense that it's a missed optimization, but
> > it's not a correctness bug.
> 
> > I'm not advocating for adding unsafe blocks to skip bounds checks.
> >
> > And, fine, there are probably a few cases where it works reliably and
> > has no real replacement. Such as the VTABLE_DEFAULT_ERROR check. But I
> > do not think bounds checks are a place where it's a good idea.
> 
> There may be no guarantees, but it is a similar situation as for C
> compilers in the kernel.

I don't think it is like that at all. We rely on non-guaranteed behavior
for data races because we have no choice and we had extensive discussion
about it with the compiler folks who are comfortable with us using that
particular exception.

> Compilers can of course change behavior and have bugs and so on, and
> thus avoiding to rely on it as much as possible is a good idea, but I
> think it is a good idea to get build asserts reliably working as much
> as possible for certain use cases. In particular, I don't see why
> simple (local-enough) bounds checks cannot be one of those (it may not
> be today, but it could).
> 
> Of course, the best would be to get the language to a point where it
> supports this sort of thing natively. But that is a longer road.
> 
> And, in some situations, there may be no good alternative (i.e. const
> eval / generics / macros may be too painful to apply), and thus people
> may end up adding `unsafe` instead, which isn't great.

The difference is that someone adding unsafe to avoid a bounds check
screams to the reviewers that something sketchy is going on. In
comparison, drivers calling `Bounded::from_expr(_)` with a non-trivial
expression looks like entirely normal code even though it might be
relying on the precise and definitely subject-to-change details of when
LLVM is choosing to inline various functions.

If const eval / generics / macros are too painful, then perform a
runtime bounds check just like everyone who uses Rust outside of the
kernel is doing.

> In addition, I think upstream probably wants to know about this sort
> of this, i.e. sometimes the changes may be unintended (i.e. if we see
> it changing in a new nightly) and they probably like to hear about
> "obvious" optimizations not being applied, since they are potential
> easy wins for them (or, rather, avoiding regressions), as Gary
> mentions. That is also part of the value of building the kernel in
> compiler CIs etc.

I do not at all think it's obvious that upstream would be happy about
this, considering it comes with the serious trade-off of us relying on
these optimizations happening.

Alice

Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Alexandre Courbot]

On Mon Nov 24, 2025 at 7:37 PM JST, Alice Ryhl wrote:
>> Compilers can of course change behavior and have bugs and so on, and
>> thus avoiding to rely on it as much as possible is a good idea, but I
>> think it is a good idea to get build asserts reliably working as much
>> as possible for certain use cases. In particular, I don't see why
>> simple (local-enough) bounds checks cannot be one of those (it may not
>> be today, but it could).
>> 
>> Of course, the best would be to get the language to a point where it
>> supports this sort of thing natively. But that is a longer road.
>> 
>> And, in some situations, there may be no good alternative (i.e. const
>> eval / generics / macros may be too painful to apply), and thus people
>> may end up adding `unsafe` instead, which isn't great.
>
> The difference is that someone adding unsafe to avoid a bounds check
> screams to the reviewers that something sketchy is going on. In
> comparison, drivers calling `Bounded::from_expr(_)` with a non-trivial
> expression looks like entirely normal code even though it might be
> relying on the precise and definitely subject-to-change details of when
> LLVM is choosing to inline various functions.
>
> If const eval / generics / macros are too painful, then perform a
> runtime bounds check just like everyone who uses Rust outside of the
> kernel is doing.

I think that what would be happening is more likely to be another
behavior we see in Rust outside of the kernel (and inside as well, tbf):
the proliferation of calls to unsafe `_unchecked` variants.

That's the direction I was looking at when I thought `from_expr`
couldn't be salvaged - I even converted the whole Nova code to use it.

In some cases, it doesn't look too bad: for instance, when creating a
`Bounded` from a bitfield, we have the mask and shift right above and
it's easy to write a convincing safety statement.

For others, I was pondering whether I should make the containing method
fallible because things could change in more subtle ways, and I wasn't
too sure that one would think about revisiting the call to
`new_unchecked` if that happened. The benefit of `from_expr` in these
cases is that it throws an error if the code changes in a breaking way,
giving you more confidence when making assumptions about values than
you can with an `unsafe` statement. This results in simpler call
overall.

Now I fully agree that its use should be limited to very simple
expressions. I tried to stress that in the documentation, but I'm fine
with hammering it more.

And apart from the little oopsie with the missing inline directive, this
has worked well enough so far that we have no need for a
`Bounded::new_unchecked` yet, which I find nice as it reduces the number
of unsafe blocks in the code.

Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Gary Guo]

On Mon, 24 Nov 2025 10:37:08 +0000
Alice Ryhl <aliceryhl@google.com> wrote:

> On Fri, Nov 21, 2025 at 04:53:26PM +0100, Miguel Ojeda wrote:
> > On Fri, Nov 21, 2025 at 3:44 PM Alice Ryhl <aliceryhl@google.com> wrote:  
> > >
> > > You say that this kind of thing would be a compiler bug, but I don't
> > > think the compiler devs folks would agree with us on that at all. I
> > > mean, sure, it's a bug in the sense that it's a missed optimization, but
> > > it's not a correctness bug.  
> >   
> > > I'm not advocating for adding unsafe blocks to skip bounds checks.
> > >
> > > And, fine, there are probably a few cases where it works reliably and
> > > has no real replacement. Such as the VTABLE_DEFAULT_ERROR check. But I
> > > do not think bounds checks are a place where it's a good idea.  
> > 
> > There may be no guarantees, but it is a similar situation as for C
> > compilers in the kernel.  
> 
> I don't think it is like that at all. We rely on non-guaranteed behavior
> for data races because we have no choice and we had extensive discussion
> about it with the compiler folks who are comfortable with us using that
> particular exception.

This is not about LKMM but that BUILD_BUG_ON also relies on compiler
optimizations and reference undefined symbols if compiler cannot
optimize them out.

`build_assert` is just a nicer Rust way of the same trick.

> 
> > Compilers can of course change behavior and have bugs and so on, and
> > thus avoiding to rely on it as much as possible is a good idea, but I
> > think it is a good idea to get build asserts reliably working as much
> > as possible for certain use cases. In particular, I don't see why
> > simple (local-enough) bounds checks cannot be one of those (it may not
> > be today, but it could).
> > 
> > Of course, the best would be to get the language to a point where it
> > supports this sort of thing natively. But that is a longer road.
> > 
> > And, in some situations, there may be no good alternative (i.e. const
> > eval / generics / macros may be too painful to apply), and thus people
> > may end up adding `unsafe` instead, which isn't great.  
> 
> The difference is that someone adding unsafe to avoid a bounds check
> screams to the reviewers that something sketchy is going on. In
> comparison, drivers calling `Bounded::from_expr(_)` with a non-trivial
> expression looks like entirely normal code even though it might be
> relying on the precise and definitely subject-to-change details of when
> LLVM is choosing to inline various functions.
> 
> If const eval / generics / macros are too painful, then perform a
> runtime bounds check just like everyone who uses Rust outside of the
> kernel is doing.

There're 200+ uses of BUILD_BUG_ON in include/. I see this case being
similar to those usages.

> 
> > In addition, I think upstream probably wants to know about this sort
> > of this, i.e. sometimes the changes may be unintended (i.e. if we see
> > it changing in a new nightly) and they probably like to hear about
> > "obvious" optimizations not being applied, since they are potential
> > easy wins for them (or, rather, avoiding regressions), as Gary
> > mentions. That is also part of the value of building the kernel in
> > compiler CIs etc.  
> 
> I do not at all think it's obvious that upstream would be happy about
> this, considering it comes with the serious trade-off of us relying on
> these optimizations happening.

If the exact use case does not involve a reference, it's exactly same
as BUILD_BUG_ON, so would be a LLVM bug that equally affect
clang-built-linux.

Best,
Gary

Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Alexandre Courbot]

On Fri Nov 21, 2025 at 11:30 PM JST, Gary Guo wrote:
> On Fri, 21 Nov 2025 15:21:45 +0100
> Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>
>> On Fri, Nov 21, 2025 at 3:10 PM Alice Ryhl <aliceryhl@google.com> wrote:
>> >
>> > This kind of thing is why I keep saying build_error() is too fragile to
>> > be used at all.  
>
> The case here I think is a perfectly fine use case of `build_error` as
> it's completely by-value and does involve references. If compiler can't
> figure out, it's either a compiler bug or a source bug.
>
>> Adding `unsafe` blocks for things that should be able to be statically
>> known isn't great.
>> 
>> `build_assert!` is just too useful, so it is best to try to understand
>> what can be done, or find an equivalent solution. Gary et al. may have
>> some input here.
>
> I'd argue that these build issues actually helps us catch missed
> optimisations opportunities :)
>
> For this particular issue, I noticed that none of the functions
> involved here (`from_expr` and `fits_within`) are marked as `#[inline]`.
> I suspect after marking them as inline this case should be resolved.

The failing config features this setting:

    CONFIG_CC_OPTIMIZE_FOR_SIZE=y

I don't know whether this "CC" setting also affects Rust, but assuming
it does, we can very well imagine that at least one of
`from_expr`/`fits_within` does not get inlined, causing the compiler to
not be able to satisfy the `build_assert`.

If that's true, then this is an oversight of mine rather than a
fundamental problem, and could affect all architectures. I'll try to
reproduce the issue locally to test this theory.

Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Miguel Ojeda]

On Fri, Nov 21, 2025 at 4:27 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
>     CONFIG_CC_OPTIMIZE_FOR_SIZE=y
>
> I don't know whether this "CC" setting also affects Rust, but assuming
> it does, we can very well imagine that at least one of
> `from_expr`/`fits_within` does not get inlined, causing the compiler to
> not be able to satisfy the `build_assert`.
>
> If that's true, then this is an oversight of mine rather than a
> fundamental problem, and could affect all architectures. I'll try to
> reproduce the issue locally to test this theory.

Yes, it does affect Rust, i.e. we use the same levels for both.

Would `inline(always)` work?

Cheers,
Miguel

Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Alexandre Courbot]

On Sat Nov 22, 2025 at 12:30 AM JST, Miguel Ojeda wrote:
> On Fri, Nov 21, 2025 at 4:27 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>>
>>     CONFIG_CC_OPTIMIZE_FOR_SIZE=y
>>
>> I don't know whether this "CC" setting also affects Rust, but assuming
>> it does, we can very well imagine that at least one of
>> `from_expr`/`fits_within` does not get inlined, causing the compiler to
>> not be able to satisfy the `build_assert`.
>>
>> If that's true, then this is an oversight of mine rather than a
>> fundamental problem, and could affect all architectures. I'll try to
>> reproduce the issue locally to test this theory.
>
> Yes, it does affect Rust, i.e. we use the same levels for both.
>
> Would `inline(always)` work?

I've repro'd the issue locally using the very helpful script mentioned
in the report, and confirmed that `#[inline(always)]` fixes the problem!

Preparing a patch. :)

Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Miguel Ojeda]

On Fri, Nov 21, 2025 at 2:41 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> I notice that loongarch is a Tier 2 Rust platform, but I suppose that's
> not an excuse to let it not build? ^_^;

x86_64, arm64 and riscv64 should be kept working, and I also
build-test loongarch64, including for stable kernels.

arm32 and UML are the ones that are best-effort (on my side at least)
so we play catch up as time allows, but loongarch64 so far should
always build and it would be sad to drop that.

I don't see this in my tests (though I see another issue for
loongarch64; I will send a few emails), so it may depend on the
config.

Cc'ing our toolchain experts and the loongarch maintainers.

Cheers,
Miguel