Re: [PATCH net-next v3 4/8] rust: time: Implement addition of Ktime and Delta

[Boqun Feng <boqun.feng@gmail.com>]

On Thu, Oct 17, 2024 at 06:33:23PM +0200, Miguel Ojeda wrote:
> On Thu, Oct 17, 2024 at 11:31 AM FUJITA Tomonori
> <fujita.tomonori@gmail.com> wrote:
> >
> > We could add the Rust version of add_safe method. But looks like
> > ktime_add_safe() is used by only some core systems so we don't need to
> > add it now?
> 
> There was some discussion in the past about this -- I wrote there a
> summary of the `add` variants:
> 
>     https://lore.kernel.org/rust-for-linux/CANiq72ka4UvJzb4dN12fpA1WirgDHXcvPurvc7B9t+iPUfWnew@mail.gmail.com/
> 
> I think this is a case where following the naming of the C side would
> be worse, i.e. where it is worth not applying our usual guideline.
> Calling something `_safe`/`_unsafe` like the C macros would be quite
> confusing for Rust.
> 
> Personally, I would prefer that we stay consistent, which will help
> when dealing with more code. That is (from the message above):
> 
>   - No suffix: not supposed to wrap. So, in Rust, map it to operators.
>   - `_unsafe()`: wraps. So, in Rust, map it to `wrapping` methods.
>   - `_safe()`: saturates. So, in Rust, map it to `saturating` methods.
> 
> (assuming I read the C code correctly back then.)
> 
> And if there are any others that are Rust-unsafe, then map it to
> `unchecked` methods, of course.
> 

The point I tried to make is that `+` operator of Ktime can cause
overflow because of *user inputs*, unlike the `-` operator of Ktime,
which cannot cause overflow as long as Ktime is implemented correctly
(as a timestamp). Because the overflow possiblity is exposed to users,
then we need to 1) document it and 2) provide saturating_add() (maybe
also checked_add() and overflowing_add()) so that users won't need to do
the saturating themselves:

	let mut kt = Ktime::ktime_get();
	let d: Delta = <maybe a userspace input>;

	// kt + d may overflow, so checking
	if let Some(_) = kt.as_ns().checked_add(d.as_nanos()) {
	    // not overflow, can add
	    kt = kt + d;
	} else {
	    // set kt to KTIME_SEC_MAX
	}

instead, they can do:

	let kt = Ktime::ktime_get();
	let d: Delta = <maybe a userspace input>;

	kt = kt.saturating_add(d);

but one thing I'm not sure is since it looks like saturating to
KTIME_SEC_MAX is the current C choice, if we want to do the same, should
we use the name `add_safe()` instead of `saturating_add()`? FWIW, it
seems harmless to saturate at KTIME_MAX to me. So personally, I like
what Alice suggested.

Hope these make sense.

Regards,
Boqun

> Cheers,
> Miguel