[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54328318-c235-413a-a069-5ea93f1dcb2b@kernel.org>
Date: Tue, 21 Oct 2025 16:46:48 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, aliceryhl@...gle.com,
daniel.almeida@...labora.com, a.hindborg@...nel.org, alex.gaynor@...il.com,
ojeda@...nel.org, anna-maria@...utronix.de, bjorn3_gh@...tonmail.com,
boqun.feng@...il.com, frederic@...nel.org, gary@...yguo.net,
jstultz@...gle.com, linux-kernel@...r.kernel.org, lossin@...nel.org,
lyude@...hat.com, rust-for-linux@...r.kernel.org, sboyd@...nel.org,
tglx@...utronix.de, tmgross@...ch.edu,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v2 1/2] rust: add udelay() function
On 10/21/25 4:39 PM, Miguel Ojeda wrote:
> Now, for runtime values, since random drivers will call this with
> possibly computed values based on who knows what, a warn once may be
> too much. A debug assert instead would be less risky if it makes
> people more comfortable.
Exactly, also consider that MAX_UDELAY_MS depends on the architecture and HZ.
Given that we'd have a WARN() for any value passed that is > MAX_UDELAY_MS, and
given that WARN() is considered a vulnerability if hit (Greg, please correct me
if that's wrong), this would literally become a vulnerability generator. :)
Powered by blists - more mailing lists