Re: [PATCH 0/4] Fix forward()/expires() racing with concurrent arming

[FUJITA Tomonori <tomo@flapping.org>]

On Tue, 18 Aug 2026 11:02:27 +0200
Andreas Hindborg <a.hindborg@kernel.org> wrote:

>> perf and CFS bandwidth have a flag as well as a lock. The flag is "do
>> not arm while armed", which is the same rule the types enforce
>> here. rtc and the softlockup watchdog look like they cancel first and
>> then start instead. None of them arms a timer that is active, so I
>> would rather the abstraction did not allow it either. Does that seem
>> reasonable?
> 
> I am fine with preventing starting a timer that is Started or Running,
> but I am not liking the `UniqueArc` requirement.
> 
> I have a use case in `rnull` where I have to start a timer behind an
> `Arc` with no way to obtain a `UniqueArc`, so I would prefer if that use
> case keeps on working. Without this, I would have to allocate a box and
> put it behind a lock, leading to double indirection.

Before the UniqueArc requirement, I would like to check which timer
you have in mind? The bandwidth timer, the per-command timer, or
something else? The two seem to need different things, so I would
rather not guess.

For the bandwidth timer I do not see where the handle would live, and that
is independent of UniqueArc. start() returns a handle that cancels the
timer when it is dropped, so it has to be kept somewhere, and the current
hrtimer API is the same. queue_rq() only gets a shared borrow of the queue
data, and the handle owns an Arc<T>, so putting it inside T means T holds a
refcount on itself and is never freed.