On Tue, Dec 02, 2025 at 10:47:04AM +0100, Ard Biesheuvel wrote: > On Tue, 2 Dec 2025 at 10:35, Mark Rutland <[email protected]> wrote: > > On Tue, Dec 02, 2025 at 10:15:22AM +0100, Ard Biesheuvel wrote: > > > On Mon, 1 Dec 2025 at 19:20, Ryan Roberts <[email protected]> wrote: > > > > I've got bot warnings because this is being called from noinstr code. I > > > > guess > > > > the best option is to just move add_random_kstack_offset() to after > > > > instrumentation is enabled for the affected arches. > > > > > > Just put instrumentation_begin()/instrumentation_end() around the call > > > to prandom_u32_state() - that seems to be the common approach for > > > punching holes into the 'noinstr' validation. > > > > That silences the warning, but isn't necessarily safe, so please DO NOT > > do that blindly. > > Oops - sorry about that.
No problem! I just wanted to make sure we didn't start to gain broken usage that'd need an audit and cleanup. [...] > Given that prandom_u32_state() does a fairly straight-forward mangle > of 4 32-bit words, might it be better to make that __always_inline > itself? Possibly! I don't know whether it's better to have prandom_u32_state() inline or out-of-line. So long as prandom_u32_state() doesn't call out to instrumented code, making it an __always_inline function will be safe. Mark.
