Re: [PATCH] sched/psi: initialize *flags in psi_memstall_enter when PSI is disabled

[Johannes Weiner]

On Thu, Apr 09, 2026 at 12:14:50AM +0800, Mashiro Chen wrote:
> Hi Johannes,
> 
> Good question. You're right that KMSAN's stack tracking persisting
> across page reuse boundaries is arguably a tool limitation. That said,
> I think fixing it on the PSI side is still reasonable:
> 
> psi_memstall_enter() takes a pointer parameter with an implicit contract:
> if the caller passes &flags, they expect *flags to be initialized upon
> return. The current early-return silently violates that contract by
> leaving *flags uninitialized, even though the value is never actually used
> functionally.

The caller has no expectations towards the contents of *flags and no
business reading or manipulating them. It's an opaque channel that
lets _enter() communicate with _leave().

> The fix is essentially free (we're already in the early-return path) and
> makes the contract explicit. You're right that the original patch lacked
> a comment explaining this, I should have added:
> 
>      /* Initialize to 0 even in psi_disabled case to honor the
>       * implicit API contract that *flags is initialized on return.
>       * psi_memstall_leave() also returns early when psi_disabled
>       * and does not read *flags, so this is zero-cost. */
>      *flags = 0;
>      return;
> 
> That said, if you prefer this stays in KMSAN (e.g., treating stack
> variables as out-of-scope once their frame returns), I'm happy to drop
> the patch and redirect the effort there instead.

It sounds to me like this would be a good thing to fix regardless of
what psi is doing here. Even if psi initialized it to some value that
is meaningful to psi - that value is totally random, and for all
intents and purposes "uninitialized", from the view of a subsequent
user of that stack slot?