public inbox for rust-for-linux@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Hindborg <a.hindborg@kernel.org>
To: "FUJITA Tomonori" <fujita.tomonori@gmail.com>
Cc: <boqun.feng@gmail.com>,  <alex.gaynor@gmail.com>,
	 <ojeda@kernel.org>, <aliceryhl@google.com>,
	 <anna-maria@linutronix.de>, <bjorn3_gh@protonmail.com>,
	 <dakr@kernel.org>,  <frederic@kernel.org>, <gary@garyguo.net>,
	 <jstultz@google.com>, <linux-kernel@vger.kernel.org>,
	 <lossin@kernel.org>, <lyude@redhat.com>,
	 <rust-for-linux@vger.kernel.org>, <sboyd@kernel.org>,
	 <tglx@linutronix.de>,  <tmgross@umich.edu>
Subject: Re: [PATCH] rust: time: Seal the ClockSource trait
Date: Thu, 19 Jun 2025 14:57:12 +0200	[thread overview]
Message-ID: <8734bv7utz.fsf@kernel.org> (raw)
In-Reply-To: <20250619.203319.1745503493999032815.fujita.tomonori@gmail.com> (FUJITA Tomonori's message of "Thu, 19 Jun 2025 20:33:19 +0900")

"FUJITA Tomonori" <fujita.tomonori@gmail.com> writes:

> On Thu, 19 Jun 2025 11:31:08 +0200
> Andreas Hindborg <a.hindborg@kernel.org> wrote:
>
>> "FUJITA Tomonori" <fujita.tomonori@gmail.com> writes:
>>
>>> On Wed, 18 Jun 2025 21:13:07 +0200
>>> Andreas Hindborg <a.hindborg@kernel.org> wrote:
>>>
>>>> "Boqun Feng" <boqun.feng@gmail.com> writes:
>>>>
>>>>> On Tue, Jun 17, 2025 at 05:10:42PM -0700, Boqun Feng wrote:
>>>>>> On Wed, Jun 18, 2025 at 08:20:53AM +0900, FUJITA Tomonori wrote:
>>>>>> > Prevent downstream crates or drivers from implementing `ClockSource`
>>>>>> > for arbitrary types, which could otherwise leads to unsupported
>>>>>> > behavior.
>>>>>> >
>>>>>>
>>>>>> Hmm.. I don't think other impl of `ClockSource` is a problem, IIUC, as
>>>>>> long as the ktime_get() can return a value in [0, i64::MAX). Also this
>>>>>> means ClockSource should be an `unsafe` trait, because the correct
>>>>>> implementaion relies on ktime_get() returns the correct value. This is
>>>>>> needed even if you sealed ClockSource trait.
>>>>>>
>>>>>> Could you drop this and fix that the ClockSource trait instead? Thanks!
>>>>>>
>>>>>
>>>>> For example:
>>>>>
>>>>>     /// Trait for clock sources.
>>>>>     ///
>>>>>     /// ...
>>>>>     /// # Safety
>>>>>     ///
>>>>>     /// Implementers must ensure `ktime_get()` return a value in [0,
>>>>>     //  KTIME_MAX (i.e. i64::MAX)).
>>>>>     pub unsafe trait ClockSource {
>>>>>         ...
>>>>>     }
>>>>
>>>> Nice catch, it definitely needs to be unsafe. We should also require
>>>> correlation between ID and the value fetched by `ktime_get`.
>>>
>>> What's ID?
>>
>>
>>   pub trait ClockSource {
>>       /// The kernel clock ID associated with this clock source.
>>       ///
>>       /// This constant corresponds to the C side `clockid_t` value.
>>       const ID: bindings::clockid_t;
>>
>> The constant used to identify the clock source when calling into C APIs.
>
> Ah, I see. Sorry to ask another question, but can we require
> correlation between ID and the value fetched by `ktime_get`?

Yes, I think we should. As in, `ClockSource::ktime_get` must return the
time associated with the clock specified by `ClockSource::ID`.

>The value
> fetched by ktime_get is opaque, isn't it?

It is, but the implementation must still fetch the correct counter, right?
Not sure if it could lead to UB if it did not though 🤷


Best regards,
Andreas Hindborg




  reply	other threads:[~2025-06-19 12:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-17 23:20 [PATCH] rust: time: Seal the ClockSource trait FUJITA Tomonori
2025-06-18  0:10 ` Boqun Feng
2025-06-18  5:01   ` Boqun Feng
2025-06-18 19:13     ` Andreas Hindborg
2025-06-18 19:29       ` Boqun Feng
2025-06-19  0:23         ` FUJITA Tomonori
2025-06-19  0:27           ` Boqun Feng
2025-06-19  0:28       ` FUJITA Tomonori
2025-06-19  9:31         ` Andreas Hindborg
2025-06-19 11:33           ` FUJITA Tomonori
2025-06-19 12:57             ` Andreas Hindborg [this message]
2025-06-19 13:38               ` Boqun Feng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8734bv7utz.fsf@kernel.org \
    --to=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=anna-maria@linutronix.de \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=frederic@kernel.org \
    --cc=fujita.tomonori@gmail.com \
    --cc=gary@garyguo.net \
    --cc=jstultz@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=lyude@redhat.com \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=sboyd@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tmgross@umich.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox