[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250711.153729.1327324726276230605.fujita.tomonori@gmail.com>
Date: Fri, 11 Jul 2025 15:37:29 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: a.hindborg@...nel.org
Cc: lyude@...hat.com, rust-for-linux@...r.kernel.org,
fujita.tomonori@...il.com, boqun.feng@...il.com, frederic@...nel.org,
tglx@...utronix.de, anna-maria@...utronix.de, jstultz@...gle.com,
sboyd@...nel.org, ojeda@...nel.org, alex.gaynor@...il.com,
gary@...yguo.net, bjorn3_gh@...tonmail.com, lossin@...nel.org,
aliceryhl@...gle.com, tmgross@...ch.edu, dakr@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rust: time: Pass correct timer mode ID to
hrtimer_start_range_ns
On Fri, 11 Jul 2025 08:18:37 +0200
Andreas Hindborg <a.hindborg@...nel.org> wrote:
> "Lyude Paul" <lyude@...hat.com> writes:
>
>> While rebasing rvkms I noticed that timers I was setting seemed to have
>> pretty random timer values that amounted slightly over 2x the time value I
>> set each time. After a lot of debugging, I finally managed to figure out
>> why: it seems that since we moved to Instant and Delta, we mistakenly
>> began passing the clocksource ID to hrtimer_start_range_ns, when we should
>> be passing the timer mode instead. Presumably, this works fine for simple
>> relative timers - but immediately breaks on other types of timers.
>>
>> So, fix this by passing the ID for the timer mode instead.
>>
>> Signed-off-by: Lyude Paul <lyude@...hat.com>
>> Cc: FUJITA Tomonori <fujita.tomonori@...il.com>
>> Fixes: fcc1dd8c8656 ("rust: time: Make HasHrTimer generic over HrTimerMode")
>
> Wow, thanks! Miguel, can you take this through rust-fixes?
I think that this patch fixes the commit in timekeeping-next.
`fcc1dd8c8656` doesn't match to the commit in the current
timekeeping-next (this patch might have been made against the tree
before it was rebased).
Powered by blists - more mailing lists