diff options
| author | FUJITA Tomonori <fujita.tomonori@gmail.com> | 2026-09-25 08:25:30 +0900 |
|---|---|---|
| committer | Andreas Hindborg <a.hindborg@kernel.org> | 2026-09-28 17:10:45 +0200 |
| commit | a9aba476d42df2537403f97f185a2b1979d0dd97 (patch) | |
| tree | fa2a04bb2dd4054891cb5b0e3469d3382ab426a4 /scripts/checkpatch.pl | |
| parent | 4ebfdb2c8b28eb8ef85b4e4ce65e55bd5a4df8d5 (diff) | |
| download | linux-next-a9aba476d42df2537403f97f185a2b1979d0dd97.tar.gz linux-next-a9aba476d42df2537403f97f185a2b1979d0dd97.zip | |
rust: time: add Delta::to_jiffies_timeout() for timeout conversion
The boundaries of __msecs_to_jiffies() and nsecs_to_jiffies64() depend
on which HZ branch is compiled. With CONFIG_HZ_300
nsecs_to_jiffies64() overflows after 64.99 years, which is less than
the 292 years a Delta can hold. With HZ=1000 a jiffy is a millisecond,
so __msecs_to_jiffies() returns its argument unchanged and never caps
it at MAX_JIFFY_OFFSET.
Compute the conversion in Rust with mul_u64_add_u64_div_u64() instead. It
returns (a * b + c) / d, computing a * b internally in 128 bits, so
ceil(nanos * HZ / NSEC_PER_SEC) needs no input clamp and rounds once. The
bound then follows from the arithmetic: with HZ <= NSEC_PER_SEC, which a
static_assert() checks, the result is at most the nanosecond count.
Unless the result saturates, the value is rounded up, so the timeout is
never shorter than the requested span. It saturates at zero jiffies for a
negative span, i.e. an immediate timeout, and at MAX_JIFFY_OFFSET, the
upper bound the kernel uses for a jiffies span. Since MAX_JIFFY_OFFSET is
derived from long, only 32 bit can reach it, and a saturated timeout there
is finite, so it can be shorter than the requested span.
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://msgid.link/20260924232530.446588-3-tomo@flapping.org
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Diffstat (limited to 'scripts/checkpatch.pl')
0 files changed, 0 insertions, 0 deletions
