netdev - Re: [PATCH v8 3/7] rust: time: Introduce Instant type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20250124.105058.869129840829208535.fujita.tomonori@gmail.com>
Date: Fri, 24 Jan 2025 10:50:58 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: miguel.ojeda.sandonis@...il.com
Cc: fujita.tomonori@...il.com, linux-kernel@...r.kernel.org,
 boqun.feng@...il.com, rust-for-linux@...r.kernel.org,
 netdev@...r.kernel.org, andrew@...n.ch, hkallweit1@...il.com,
 tmgross@...ch.edu, ojeda@...nel.org, alex.gaynor@...il.com,
 gary@...yguo.net, bjorn3_gh@...tonmail.com, benno.lossin@...ton.me,
 a.hindborg@...sung.com, aliceryhl@...gle.com, anna-maria@...utronix.de,
 frederic@...nel.org, tglx@...utronix.de, arnd@...db.de,
 jstultz@...gle.com, sboyd@...nel.org, mingo@...hat.com,
 peterz@...radead.org, juri.lelli@...hat.com, vincent.guittot@...aro.org,
 dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
 mgorman@...e.de, vschneid@...hat.com
Subject: Re: [PATCH v8 3/7] rust: time: Introduce Instant type

On Sat, 18 Jan 2025 13:15:42 +0100
Miguel Ojeda <miguel.ojeda.sandonis@...il.com> wrote:

> On Fri, Jan 17, 2025 at 12:31 AM FUJITA Tomonori
> <fujita.tomonori@...il.com> wrote:
>>
>> As I wrote to Tom, that's the kernel's assumption. Do we need to make
>> it an invariant too?
>>
>> Or improving the above "Range from 0 to `KTIME_MAX.`" is enough?
>>
>> The kernel assumes that the range of the ktime_t type is from 0 to
>> KTIME_MAX. The ktime APIs guarantees to give a valid ktime_t.
> 
> It depends on what is best for users, i.e. if there are no use cases
> where this needs to be negative, then why wouldn't we have the
> invariant documented? Or do we want to make it completely opaque?

Instant object is always created via ktime_get() so it shouldn't be
negative. ktime_t is opaque for users. However, we support creating a
Delta object from the difference between two Instance objects:

Delta = Instant1 - Instant2

It's a subtraction of two s64 types so to prevent overflow, the range
of ktime_t needs to be limited.

I'll add the invariant doc. I'm not sure if an invariant document
is the best choice, but in any case, the above information should be
documented.