Received-SPF: pass (google.com: domain of linux-kernel+bounces-177723-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <Zigj-lY5lnBSKuib@boqun-archlinux> <87cypvnpwn.ffs@tglx>
In-Reply-To: <87cypvnpwn.ffs@tglx>
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date: Mon, 13 May 2024 17:04:43 +0200
Message-ID: <CANiq72nGHhgRjfMOhz=ss51q2egHYexPMVvWTr0RES9WAmMF=A@mail.gmail.com>
Subject: Re: [PATCH 2/2] rust: time: Use wrapping_sub() for Ktime::sub()
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Boqun Feng <boqun.feng@gmail.com>, Miguel Ojeda <ojeda@kernel.org>, 
	John Stultz <jstultz@google.com>, Stephen Boyd <sboyd@kernel.org>, 
	Alex Gaynor <alex.gaynor@gmail.com>, Wedson Almeida Filho <wedsonaf@gmail.com>, Gary Guo <gary@garyguo.net>, 
	bjorn3_gh@protonmail.com, Benno Lossin <benno.lossin@proton.me>, 
	Andreas Hindborg <a.hindborg@samsung.com>, Alice Ryhl <aliceryhl@google.com>, 
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, 
	Kees Cook <keescook@chromium.org>, Mara Bos <m-ou.se@m-ou.se>, 
	"Amanieu d'Antras" <amanieu@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 9, 2024 at 2:14=E2=80=AFPM Thomas Gleixner <tglx@linutronix.de>=
 wrote:
>
> In principle ktime_sub() should not overflow for regular use cases.
>
> If the binder example overflows the substraction, then something is
> seriously wrong. Though in that case as it's only for debug purposes
> panicing would be totally counter productive. A warning might be
> appropriate though.

Thanks for the clarification Thomas.

Alice and I pinged about this in the RustNL Unconf, i.e. about having
a way to customize what happens on integer overflow (and, in general,
other panics too), which I had in:

    https://github.com/Rust-for-Linux/linux/issues/354

e.g. like UBSan that allows a "report and continue" option.

We chatted with Mara and Amanieu, who were receptive. In particular,
Mara posted right away:

    https://github.com/rust-lang/rfcs/pull/3632

as a possible first step to eventually have that ability, mentioning
Rust for Linux as a user.

If we get the ability to customize those, then this could simply be a
normal arithmetic operation, i.e. like any other. That is, considered
to be a bug if it overflows.

Meanwhile, one alternative is going with Boqun's approach, but I would
just use the standard operator (i.e. what we do elsewhere) and try to
get the customization happen as soon as possible since we will need it
for everything else (plus we avoid to make the code uglier with
changes that we will need to revert anyway; and it also allows us to
easily test any new customization feature from the compiler/library).

Cheers,
Miguel