All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Hindborg <a.hindborg@kernel.org>
To: FUJITA Tomonori <tomo@flapping.org>
Cc: tomo@flapping.org, gary@garyguo.net, ojeda@kernel.org,
	acourbot@nvidia.com, aliceryhl@google.com,
	anna-maria@linutronix.de, bjorn3_gh@protonmail.com,
	boqun@kernel.org, dakr@kernel.org, daniel.almeida@collabora.com,
	frederic@kernel.org, jstultz@google.com, lossin@kernel.org,
	lyude@redhat.com, sboyd@kernel.org, tamird@kernel.org,
	tglx@kernel.org, tmgross@umich.edu, work@onurozkan.dev,
	rust-for-linux@vger.kernel.org, fujita.tomonori@gmail.com
Subject: Re: [PATCH 0/4] Fix forward()/expires() racing with concurrent arming
Date: Fri, 21 Aug 2026 09:13:01 +0200	[thread overview]
Message-ID: <87bjaw7xqa.fsf@kernel.org> (raw)
In-Reply-To: <20260820.215332.1257209020327006274.tomo@flapping.org>

FUJITA Tomonori <tomo@flapping.org> writes:

> On Thu, 20 Aug 2026 14:34:16 +0200
> Andreas Hindborg <a.hindborg@kernel.org> wrote:
>
>>>> We discussed this at the call last night. We came to the conclusion that
>>>> we would like to experiment with the solution outlined by Gary, where we
>>>> inject `expires` into the callback handler, and the callback handler
>>>> returns a forward duration in addition to a restart value. Because with
>>>> that approach, we can avoid adding complexity to the Arc end of the API.
>>>> 
>>>> For the best implementation of this scheme, we probably need to change
>>>> some bits in the C code, add an additional path. Down the line, we could
>>>> also see how man callers of the C code can be changed to use this
>>>> pattern.
>>>> 
>>>> Do you want to send a patch based on this solution Tomo?
>>>
>>> https://lore.kernel.org/rust-for-linux/20260814.084700.1697518597717457311.tomo@flapping.org/
>>>
>>> The solution that we discussed before, right? It changes how the
>>> hrtimer core calls the callback. If the C maintainers take that, I
>>> will do the Rust side for it.
>> 
>> Yes this one. We don't know if C maintainers will like it. We were
>> discussing having a separate path on the C side just for just,
>> alternatively converting C side callers.
>> 
>> I think we should be able to reach some kind of agreement with C
>> timekeeping. But if not, we can solve it on rust side only, but less
>> efficient. We can grab the base lock again, read expires, then drop the
>> lock. But better to do it in the C code.
>
> The Rust side cannot take the base lock: lock_hrtimer_base() is static
> in kernel/time/hrtimer.c, internal to the core. So that way needs some
> agreement with the C maintainers as well.

Right, we would have to export the symbol, or a function for this
purpose. But it is a smaller change to C code. I would prefer we solve
it properly though, not with hacks.


Best regards,
Andreas Hindborg

r


  reply	other threads:[~2026-08-21  7:13 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13 13:48 [PATCH 0/4] Fix forward()/expires() racing with concurrent arming FUJITA Tomonori
2026-08-13 13:48 ` [PATCH v1 1/4] rust: hrtimer: Introduce HrTimerArc to make arming exclusive FUJITA Tomonori
2026-08-13 13:48 ` [PATCH v1 2/4] rust: hrtimer: Introduce HrTimerPin " FUJITA Tomonori
2026-08-13 13:48 ` [PATCH v1 3/4] rust: hrtimer: Restrict expires() to safe contexts FUJITA Tomonori
2026-08-13 13:48 ` [PATCH v1 4/4] rust: hrtimer: Make HrTimer repr(transparent) FUJITA Tomonori
2026-08-13 14:16 ` [PATCH 0/4] Fix forward()/expires() racing with concurrent arming Gary Guo
2026-08-13 23:47   ` FUJITA Tomonori
2026-08-14  0:54     ` Gary Guo
2026-08-14 13:48       ` FUJITA Tomonori
2026-08-14 14:24         ` Gary Guo
2026-08-18  0:56           ` FUJITA Tomonori
2026-08-17 15:40         ` Gary Guo
2026-08-18  1:35           ` FUJITA Tomonori
2026-08-17 15:26   ` Andreas Hindborg
2026-08-18  2:26     ` FUJITA Tomonori
2026-08-18  9:02       ` Andreas Hindborg
2026-08-18 11:21         ` FUJITA Tomonori
2026-08-18 11:59           ` Andreas Hindborg
2026-08-19 13:01             ` FUJITA Tomonori
2026-08-20  9:00               ` Andreas Hindborg
2026-08-20  9:21                 ` FUJITA Tomonori
2026-08-20 12:34                   ` Andreas Hindborg
2026-08-20 12:53                     ` FUJITA Tomonori
2026-08-21  7:13                       ` Andreas Hindborg [this message]
2026-08-21  9:53                         ` FUJITA Tomonori

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=87bjaw7xqa.fsf@kernel.org \
    --to=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=aliceryhl@google.com \
    --cc=anna-maria@linutronix.de \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=frederic@kernel.org \
    --cc=fujita.tomonori@gmail.com \
    --cc=gary@garyguo.net \
    --cc=jstultz@google.com \
    --cc=lossin@kernel.org \
    --cc=lyude@redhat.com \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=sboyd@kernel.org \
    --cc=tamird@kernel.org \
    --cc=tglx@kernel.org \
    --cc=tmgross@umich.edu \
    --cc=tomo@flapping.org \
    --cc=work@onurozkan.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.