linux-kernel - Re: [PATCH 2/6] rust: hrtimer: Add HrTimerCallbackContext and ::forward()

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <878qo8bkoy.fsf@kernel.org>
Date: Thu, 10 Apr 2025 08:21:49 +0200
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Lyude Paul" <lyude@...hat.com>
Cc: <rust-for-linux@...r.kernel.org>,  <linux-kernel@...r.kernel.org>,
  "Boqun Feng" <boqun.feng@...il.com>,  "Frederic Weisbecker"
 <frederic@...nel.org>,  "Thomas Gleixner" <tglx@...utronix.de>,
  "Anna-Maria Behnsen" <anna-maria@...utronix.de>,  "Miguel Ojeda"
 <ojeda@...nel.org>,  "Alex Gaynor" <alex.gaynor@...il.com>,  "Gary Guo"
 <gary@...yguo.net>,  Björn Roy Baron
 <bjorn3_gh@...tonmail.com>,  "Benno
 Lossin" <benno.lossin@...ton.me>,  "Alice Ryhl" <aliceryhl@...gle.com>,
  "Trevor Gross" <tmgross@...ch.edu>
Subject: Re: [PATCH 2/6] rust: hrtimer: Add HrTimerCallbackContext and
 ::forward()

"Lyude Paul" <lyude@...hat.com> writes:

> On Wed, 2025-04-09 at 12:58 -0400, Lyude Paul wrote:
>>
>> Pin<&'a T> is noticeably absent, because I'm not sure it could fulfill these
>> requirements. That being said - assuming we fulfill the unique ownership
>> requirement, I believe that for all the unique aforementioned types it
>> wouldn't be possible to take out a timer handle when they're in scope anyhow.
>> So we probably could skip the cancel() call?
>
> Nope - realizing this doesn't solve the edge case of "what if someone tried
> calling a contextless forward() from within the context of the timer callback
> itself" since uniqueness doesn't actually mean the timer is cancelled. So I
> think your suggestion of returning Err() if the timer is already running might
> actually be the way to go here. I think we would still need to ensure
> uniqueness though, since that can at least guarantee that the timer won't be
> requeued between us checking it and before we manage to call
> hrtimer_forward().

We should not be able to obtain a unique reference/pointer when the
timer is armed. In this case the timer handle will somehow own the
timer, either directly, by refcount, or by reference.

At any rate, you can add this to the current series, or you can submit
it later as a separate series. I don't think we need to stall the
current series till we figure this out. But it is good to keep it in mind.


Best regards,
Andreas Hindborg