From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-y-111.mailbox.org (mout-y-111.mailbox.org [91.198.250.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 825F435B658 for ; Wed, 8 Apr 2026 16:58:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.198.250.236 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775667505; cv=none; b=kjTYzObEr3coaQRixRTxec0HKpq77QYYM3up83kMUM5i6uOQQUtZLqEte/fxQhwgu0Af10Hiq2kVoFwdpXWVxmADswbb/pMCpX5uUDqh56SDXKFPO3XCS2CRQyY/KrsY+mVCoViuU8j+qWnH7wETN0EQOF7gUHCDmKoKnywWMCE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775667505; c=relaxed/simple; bh=pUGFbZmfCs/8Gyk5ZMjhN/ah7d/cHdBpfDvUPjonWls=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rhAZQj8vaBzwLJ3F30CFk185eUketLZ3PACVQ2H+Tz3d/fe2dLKiS0bkLh5W1a514edzrhQTiDaYaYeoOPagrrE2eVNI3500jepBzfge5LlTnoAW65L5qkxZ1JVtugg54d+4lYPJLvdzCO7vUbaaZEgFsunvc5OFb99MTtvUSag= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org; spf=pass smtp.mailfrom=mailbox.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b=jZzq6v3+; arc=none smtp.client-ip=91.198.250.236 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mailbox.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b="jZzq6v3+" Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-y-111.mailbox.org (Postfix) with ESMTPS id 4frTlv4RsVz9yk9; Wed, 8 Apr 2026 18:58:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1775667499; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tFwfB43O5IhqyZQJePe5flR0eGN8dwEJK5uSwFIRxKI=; b=jZzq6v3+TIkI8TrbUqDWOMsNHpQ37G419HY5boklWmF7rL+8tKeZ4b5buZpLx4skSPtIiv ER1svN55/ZIpq+MLbQPlaT+EOT0grT8j0nL1KdSDzqj3qAH3Fvyu+YvurnU/4rkQIEi81E pedErxQTHvGIrPkfvlvAeUWlxgTBUBPX5JlSzFRZUSQCXH7Ey4tgilMUalyXiC1PChHeVL rDOPldQF+rZIV89e9vqJPE9c9Yu21rgxD08fU29OKKzB5bwvZzqQFDzH+Dldm34iHukINt 6K7sy3afavcXcPfjTly2n4DXoI4PjhetNJnJxeBT5yULVCCKmqIGYPePF2esDg== Message-ID: <199e0730-d35e-4617-b5c3-608934ecaa3d@mailbox.org> Date: Thu, 9 Apr 2026 00:58:03 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH] sched/psi: initialize *flags in psi_memstall_enter when PSI is disabled To: Johannes Weiner Cc: surenb@google.com, peterz@infradead.org, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, syzbot+4b1bd55fba6260160779@syzkaller.appspotmail.com References: <20260405055044.554243-1-mashiro.chen@mailbox.org> <754f231c-f9a0-495d-b0d8-58f8c8e4dc12@mailbox.org> Content-Language: en-US From: Mashiro Chen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-MBO-RS-ID: 51831dc803c059d2b5a X-MBO-RS-META: mcgi9p43efqz4buf5ctt8w3tcshsrrwc Hi Johannes, You're right on both counts. The 'opaque channel' framing makes it clear there's no meaningful API contract being violated here -- the caller is not supposed to interpret *flags at all. And yes, your second point is exactly the real issue: once a stack frame returns, its local variables should be considered dead. KMSAN tracking that shadow across page reuse into an unrelated frame is the actual bug. I'll drop this patch. The correct fix is in KMSAN -- it should treat stack slots as out-of-scope once their owning frame returns, rather than letting stale shadow metadata escape into subsequent users of the same physical address. Thanks for the clear explanation. Best, Mashiro Chen On 4/9/26 00:40, Johannes Weiner wrote: > 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?