[PATCH 0/4] rust: replace WARN_ONCE TODOs with pr_warn_once!

[PATCH 0/4] rust: replace WARN_ONCE TODOs with pr_warn_once!

[Adarsh Das]

Replace pr_warn and TODO comments for pr_warn_once with the macro call.

Adarsh Das (4):
  rust: error: use `pr_warn_once!` instead of `pr_warn!`
  rust: module_params: use `pr_warn_once!` instead of `pr_warn!`
  rust: mm: add `pr_warn_once!` for invalid range in
    `zap_page_range_single`
  rust: time: add `pr_warn_once!` for clamped delta in `fsleep`

 rust/kernel/error.rs        | 3 +--
 rust/kernel/mm/virt.rs      | 2 +-
 rust/kernel/module_param.rs | 3 +--
 rust/kernel/time/delay.rs   | 2 +-
 4 files changed, 4 insertions(+), 6 deletions(-)

-- 
2.53.0

[PATCH 1/4] rust: error: use `pr_warn_once!` instead of `pr_warn!`

[Adarsh Das]

Replace the temporary `pr_warn!` call with `pr_warn_once!` and remove the TODO comment.

Signed-off-by: Adarsh Das <adarshdas950@gmail.com>
---
 rust/kernel/error.rs | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/rust/kernel/error.rs b/rust/kernel/error.rs
index 258b12afdcba..562e6daa9151 100644
--- a/rust/kernel/error.rs
+++ b/rust/kernel/error.rs
@@ -124,8 +124,7 @@ pub fn from_errno(errno: crate::ffi::c_int) -> Error {
         if let Some(error) = Self::try_from_errno(errno) {
             error
         } else {
-            // TODO: Make it a `WARN_ONCE` once available.
-            crate::pr_warn!(
+            crate::pr_warn_once!(
                 "attempted to create `Error` with out of range `errno`: {}\n",
                 errno
             );
-- 
2.53.0

[PATCH 2/4] rust: module_params: use `pr_warn_once!` instead of `pr_warn!`

[Adarsh Das]

Replace the temporary `pr_warn!` call with `pr_warn_once!` and remove
the TODO comment.

Signed-off-by: Adarsh Das <adarshdas950@gmail.com>
---
 rust/kernel/module_param.rs | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/rust/kernel/module_param.rs b/rust/kernel/module_param.rs
index 6a8a7a875643..dd6d663a0a3c 100644
--- a/rust/kernel/module_param.rs
+++ b/rust/kernel/module_param.rs
@@ -62,8 +62,7 @@ pub trait ModuleParam: Sized + Copy {
     // NOTE: If we start supporting arguments without values, val _is_ allowed
     // to be null here.
     if val.is_null() {
-        // TODO: Use pr_warn_once available.
-        crate::pr_warn!("Null pointer passed to `module_param::set_param`");
+        crate::pr_warn_once!("Null pointer passed to `module_param::set_param`");
         return EINVAL.to_errno();
     }
 
-- 
2.53.0

[PATCH 3/4] rust: mm: add `pr_warn_once!` for invalid range in `zap_page_range_single`

[Adarsh Das]

Add a warning for the invalid range case and remove the TODO comment.

Signed-off-by: Adarsh Das <adarshdas950@gmail.com>
---
 rust/kernel/mm/virt.rs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rust/kernel/mm/virt.rs b/rust/kernel/mm/virt.rs
index da21d65ccd20..f608262a4ff8 100644
--- a/rust/kernel/mm/virt.rs
+++ b/rust/kernel/mm/virt.rs
@@ -116,7 +116,7 @@ pub fn end(&self) -> usize {
     pub fn zap_page_range_single(&self, address: usize, size: usize) {
         let (end, did_overflow) = address.overflowing_add(size);
         if did_overflow || address < self.start() || self.end() < end {
-            // TODO: call WARN_ONCE once Rust version of it is added
+            crate::pr_warn_once!("VMA contains invalid range\n");
             return;
         }
 
-- 
2.53.0

[PATCH 4/4] rust: time: add `pr_warn_once!` for clamped delta in `fsleep`

[Adarsh Das]

Add a warning when the delta is clamped to the maximum value and remove the TODO comment.

Signed-off-by: Adarsh Das <adarshdas950@gmail.com>
---
 rust/kernel/time/delay.rs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rust/kernel/time/delay.rs b/rust/kernel/time/delay.rs
index b5b1b42797a0..0965fcb6eb80 100644
--- a/rust/kernel/time/delay.rs
+++ b/rust/kernel/time/delay.rs
@@ -35,7 +35,7 @@ pub fn fsleep(delta: Delta) {
     let delta = if (Delta::ZERO..=MAX_DELTA).contains(&delta) {
         delta
     } else {
-        // TODO: Add WARN_ONCE() when it's supported.
+        crate::pr_warn_once!("delta out of range, clamping to maximum\n");
         MAX_DELTA
     };
 
-- 
2.53.0

Re: [PATCH 4/4] rust: time: add `pr_warn_once!` for clamped delta in `fsleep`

[FUJITA Tomonori]

On Thu, 26 Feb 2026 17:38:48 +0530
Adarsh Das <adarshdas950@gmail.com> wrote:

> Add a warning when the delta is clamped to the maximum value and remove the TODO comment.
> 
> Signed-off-by: Adarsh Das <adarshdas950@gmail.com>
> ---
>  rust/kernel/time/delay.rs | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/rust/kernel/time/delay.rs b/rust/kernel/time/delay.rs
> index b5b1b42797a0..0965fcb6eb80 100644
> --- a/rust/kernel/time/delay.rs
> +++ b/rust/kernel/time/delay.rs
> @@ -35,7 +35,7 @@ pub fn fsleep(delta: Delta) {
>      let delta = if (Delta::ZERO..=MAX_DELTA).contains(&delta) {
>          delta
>      } else {
> -        // TODO: Add WARN_ONCE() when it's supported.
> +        crate::pr_warn_once!("delta out of range, clamping to maximum\n");
>          MAX_DELTA
>      };

pr_warn_once() and WARN_ONCE() are different; WARN_ONCE() also dumps a
stack trace, which is more appropriate here, I think.

Re: [PATCH 4/4] rust: time: add `pr_warn_once!` for clamped delta in `fsleep`

[Gary Guo]

On Thu Feb 26, 2026 at 12:59 PM GMT, FUJITA Tomonori wrote:
> On Thu, 26 Feb 2026 17:38:48 +0530
> Adarsh Das <adarshdas950@gmail.com> wrote:
>
>> Add a warning when the delta is clamped to the maximum value and remove the TODO comment.
>> 
>> Signed-off-by: Adarsh Das <adarshdas950@gmail.com>
>> ---
>>  rust/kernel/time/delay.rs | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/rust/kernel/time/delay.rs b/rust/kernel/time/delay.rs
>> index b5b1b42797a0..0965fcb6eb80 100644
>> --- a/rust/kernel/time/delay.rs
>> +++ b/rust/kernel/time/delay.rs
>> @@ -35,7 +35,7 @@ pub fn fsleep(delta: Delta) {
>>      let delta = if (Delta::ZERO..=MAX_DELTA).contains(&delta) {
>>          delta
>>      } else {
>> -        // TODO: Add WARN_ONCE() when it's supported.
>> +        crate::pr_warn_once!("delta out of range, clamping to maximum\n");
>>          MAX_DELTA
>>      };
>
> pr_warn_once() and WARN_ONCE() are different; WARN_ONCE() also dumps a
> stack trace, which is more appropriate here, I think.

I think this is also true for patch 1. I think it's fine to add pr_warn_once
before we add `warn_once!()` but the TODO should be kept.

Best,
Gary

Re: [PATCH 4/4] rust: time: add `pr_warn_once!` for clamped delta in `fsleep`

[Greg KH]

On Thu, Feb 26, 2026 at 09:59:23PM +0900, FUJITA Tomonori wrote:
> On Thu, 26 Feb 2026 17:38:48 +0530
> Adarsh Das <adarshdas950@gmail.com> wrote:
> 
> > Add a warning when the delta is clamped to the maximum value and remove the TODO comment.
> > 
> > Signed-off-by: Adarsh Das <adarshdas950@gmail.com>
> > ---
> >  rust/kernel/time/delay.rs | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/rust/kernel/time/delay.rs b/rust/kernel/time/delay.rs
> > index b5b1b42797a0..0965fcb6eb80 100644
> > --- a/rust/kernel/time/delay.rs
> > +++ b/rust/kernel/time/delay.rs
> > @@ -35,7 +35,7 @@ pub fn fsleep(delta: Delta) {
> >      let delta = if (Delta::ZERO..=MAX_DELTA).contains(&delta) {
> >          delta
> >      } else {
> > -        // TODO: Add WARN_ONCE() when it's supported.
> > +        crate::pr_warn_once!("delta out of range, clamping to maximum\n");
> >          MAX_DELTA
> >      };
> 
> pr_warn_once() and WARN_ONCE() are different; WARN_ONCE() also dumps a
> stack trace, which is more appropriate here, I think.

WARN_ONCE() also will panic the machine if panic_on_warn is enabled.  As
it is done in a few billion Linux systems right now :(

So be very careful about that.

thanks,

greg k-h

Re: [PATCH 4/4] rust: time: add `pr_warn_once!` for clamped delta in `fsleep`

[Miguel Ojeda]

On Thu, Feb 26, 2026 at 3:36 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> WARN_ONCE() also will panic the machine if panic_on_warn is enabled.  As
> it is done in a few billion Linux systems right now :(
>
> So be very careful about that.

Coming back to this...

I think we should settle for cases like this (i.e. "Erroneous
Behavior") to use `debug_assert!` plus `pr_warn_once!`.

That way in normal builds, we just print a warning once, no risk of
`WARN_ONCE()`. And in truly debug builds, we assert.

This should make it easier to add such EB in most cases where needed,
and if someone really wants `WARN_ONCE()` or similar, then they can do
it explicitly.

In fact, `debug_assert!` could perhaps do the `pr_warn_once!` when
debug is not enabled, but it may be too big of a hammer. Instead, a
macro for EB to combine `debug_assert!` and `pr_warn_once!` may be
easier, i.e. leaving `debug_assert!` to be the normal `core` one.

Cheers,
Miguel

Re: [PATCH 4/4] rust: time: add `pr_warn_once!` for clamped delta in `fsleep`

[Greg KH]

On Mon, Apr 06, 2026 at 12:39:12PM +0200, Miguel Ojeda wrote:
> On Thu, Feb 26, 2026 at 3:36 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > WARN_ONCE() also will panic the machine if panic_on_warn is enabled.  As
> > it is done in a few billion Linux systems right now :(
> >
> > So be very careful about that.
> 
> Coming back to this...
> 
> I think we should settle for cases like this (i.e. "Erroneous
> Behavior") to use `debug_assert!` plus `pr_warn_once!`.
> 
> That way in normal builds, we just print a warning once, no risk of
> `WARN_ONCE()`. And in truly debug builds, we assert.

Who would ever build a "truly debug build"?  That's the overall problem
we have tried to fix up, no user will do a new build for things, so we
have dynamic debugging now.  I think only the mm core still has an
overly-strict debug mode that only the mm developers run, and even then,
there have been arguments it should be removed.

> This should make it easier to add such EB in most cases where needed,
> and if someone really wants `WARN_ONCE()` or similar, then they can do
> it explicitly.

Sure, that's fine, but note that this will crash and should NEVER happen
if it can be user triggered.  And if you are warning, well, why not just
handle the issue, print out a message, and continue on?  Why reboot
anything?

thanks,

greg k-h

Re: [PATCH 4/4] rust: time: add `pr_warn_once!` for clamped delta in `fsleep`

[Miguel Ojeda]

On Mon, Apr 6, 2026 at 1:20 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> Who would ever build a "truly debug build"?  That's the overall problem
> we have tried to fix up, no user will do a new build for things, so we
> have dynamic debugging now.  I think only the mm core still has an
> overly-strict debug mode that only the mm developers run, and even then,
> there have been arguments it should be removed.

This is primarily for developers, yeah. For instance, I boot-test in
QEMU with `CONFIG_RUST_DEBUG_ASSERTIONS=y` (and a few others as well)
in CI, and I hope developers do so as well for Rust code, at least
from time to time.

It is not meant to debug a user's machine. Well, it can actually help
a lot there, but it would only work for the rare users that can
actually rebuild a kernel etc.

In my ideal world, we would have as many (reasonable) debug asserts as
possible, including for unsafe preconditions etc.

(Certain specialized users that really want to crash everything at the
first sight of trouble may actually want even the debug checks, and in
such a case it may be important to split very heavy debug checks that
make the machine unusable etc. But those are their own world, i.e. the
idea is not to assign CVEs for these.).

> Sure, that's fine, but note that this will crash and should NEVER happen
> if it can be user triggered.  And if you are warning, well, why not just
> handle the issue, print out a message, and continue on?  Why reboot
> anything?

Yeah, `WARN_ONCE()` and panics in general need to be still justified,
by whoever really needs to use it.

i.e. just like today, no changes there.

i.e. the idea is to avoid `WARN_ONCE()`, rather than using it, for the
places where we want to apply EB. For instance, for functions where
there are really wrong (unexpected, invalid) inputs on functions that
we don't want to make fallible nor panicking nor unsafe, but we don't
simply want to ignore the issue if we can easily catch it at
development/debug time.

For instance, udelay` in C has a range of invalid inputs, and to match
that in Rust, we applied EB there. So if someone passes an out of
range delay for the equivalent function in Rust, then if they are in a
debug build, they will notice immediately (most likely a development
error or a typo etc.). And if they are in a normal build, then we
saturate at the moment (in the implementation -- the docs do not
specify what will happen, on purpose!). And there we could also have
`pr_warn_once!`.

So no panics in sight, it is just an attempt to improve over the C
equivalent of some functions, by 1) being clear in the docs what is a
valid input or not, and 2) in development, catch mistakes very early
and 3) in production, have a "sane" default behavior (and possibly a
`pr_warn_once`).

In C, the equivalent functions may or may not say in the docs what the
invalid inputs are (if they have docs to begin with). And what happens
if the inputs are actually hit is in many cases just UB, or who knows.
And while sometimes they do have sane behavior, and sometimes there
may be warnings, it really depends (sometimes it even changes over
time as the code gets maintained).

So what I am trying to get is a way to consistently mark these spots
at least for Rust, avoid UB, document them and make them easier to
debug.

I hope that clarifies (and thanks for discussing this, I think it is important).

Cheers,
Miguel

Re: [PATCH 4/4] rust: time: add `pr_warn_once!` for clamped delta in `fsleep`

[Miguel Ojeda]

On Mon, Apr 6, 2026 at 2:14 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> I hope that clarifies (and thanks for discussing this, I think it is important).

A couple more notes...

Some of these things should be done if possible in the type system
directly, i.e. we generally try to avoid invalid inputs in general,
i.e. making the caller prove they have a good value by asking for a
particular type that already has that invariant. For instance, the
Rust `udelay` perhaps could take something more narrow than a `Delta`
(which is already an improvement over C taking a primitive integer).
But sometimes this may be inconvenient (e.g. if a maintainer wants to
match a C definition), or not a simple input parameter, etc.

And regarding the debug asserts, one may see them as "inline" KUnit
tests that check things for you. Just like KUnit tests, they are not
supported in production kernels, and they are not expected to be run
by users, and (I think) we do not assign CVEs for failing KUnit tests
etc. But they make development (and maintenance!) easier. The
difference is that they can check things "on the fly", constantly, and
that the failure mode is louder [*].

[*] I guess we could have the debug assets not panic but just print a
special string and then capture those in the log with a tool etc.
etc., but that is another discussion.

Cheers,
Miguel