From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 54F0F346FCA for ; Wed, 8 Apr 2026 16:40:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775666433; cv=none; b=m7SgryExUSiTB01RrdvposJMfQPfeTgT+j7VuUrC2jPCrrJuypx0nKc+GNObEUPM6syuXJ/CXzD/YxzTR29Dpe7TmASLYVvqD5x13nYmMOxsr2NQ24UwesQvS8Jm2sqH8x+0CabGjh8+r4wlJ2JYpKGXclwOgSVmfzN2tD5PWpo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775666433; c=relaxed/simple; bh=kQg89JjVKbaoC1ht85n2VhkmcHdj/Wdua1hhQLRRyJo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kTsU/HjNIVz8Uk4dCma6SLvp5CuSMLZk09BUi9GXkqQE7h60qp9kyxiCUg14IIkoGKqTMIBJYsH4aNE7r7R+X5mGc1YlGabWrnWWN1DLbnxVeFzQ1Nu5tW/jhmrFG2FQ/AzmZnUoLJ6lS3wBOZEHNEPtxgQXEyy9aMkWvi799og= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=BLt9hyYv; arc=none smtp.client-ip=209.85.222.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="BLt9hyYv" Received: by mail-qk1-f177.google.com with SMTP id af79cd13be357-8d65f4073bfso10490885a.3 for ; Wed, 08 Apr 2026 09:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1775666430; x=1776271230; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=iZ35qKFJDkAWcMZF7vnu1sAZX9dGjhTts/QJc1T/5yU=; b=BLt9hyYvevGgaRX640EpAUmISKbtQQsOPNS25wej82M4x/YI4RO/LBWNBd3ZhaoZMC 27tu1zXCmXCNlg+Kd0SxsKKDm4vQmgwLhdW5AYE6w+qHcdozg2VtIgZIfriU5zFMj+Nu +buKFGNxL9oEATcjWx+epbBH0LWwd9R+HWsTGiNWx+9+dHFAzpln3BYXQyo/ZYf5K4JG BKS4k8FdjyYaZgzhdmfATlPQc/hbrItxDOyUQqnAM33opLWr9jFGacII9kiasn9OqPLK qQK3YR96mlemI298wTk5qUbcSI8w//WGUqBHR05u1eKBxHJ9FXlz4zzU1oknOBT5dxmy UGCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775666430; x=1776271230; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=iZ35qKFJDkAWcMZF7vnu1sAZX9dGjhTts/QJc1T/5yU=; b=YGeHPf8jD+AvsqR/NeKP2vrG0d41tbnww0isd7dJ8egIXyF19NO9aVWoNm14Jo0q0m W9U9OjLpRUS8zWQCwBmi/DGw7Irddk9bQKYoDT6sLMKS+RmW/w49e8xnyPwR9Ni/J2cy PSm7ZKXbnusTgLBPM4FUC0+RLt3UDTJbDotXvUe+YrVL7+B0duqstPR4YUPl2/90KZ36 CvrEW1Rf8QRyp0VGHCIJdZDwGcYkbDL6mFe72X69A1TV7KNiiqYQKXxzB+2SQcBH66DI 1MDsFx3+a/fEXZQ8QMwr8wDfgJwVys3TTIEns7/yM+PTxYI43EJ0rjuhaIgd6z3UbVAq Bv+A== X-Forwarded-Encrypted: i=1; AJvYcCVlSgiYoLJ2vMs0XxVI5TvjtMb1PBg2LDEEtCzqnM8cqJJ7+ZSQE5or7NtjhLbw6Av4nVv6zknITBRNoco=@vger.kernel.org X-Gm-Message-State: AOJu0YxTACNg0wRcyn1OLRJHhq1UCZvDjKpXjB1AlbJ93Si/IL+AoT82 IY8Dha+/ObD/7PJw3oBkzkDI4xpjYhgdq1jSb2H+bnz11MZCQkK16RNreo7eHRPo5Vbgb4OGbYT wcFP/ X-Gm-Gg: AeBDiesDA+B9O+s9g8uO+X3nhXASzbsnUf0RAodaA4sWcMkwneD2I4+HHZou+Kw27lw kWA7dLRhrqbqXyRNkj1+OgFgTZGbtJzx88OENp1jsdmZn7uf4bMsxG+dS0HVww6ZYaa5PWjGRKw ZT/V4p090dtFyBH+RQv9MojxGLJPIovw414gqKhc2Z6Vk7szqaVNQcw+29a84HaQLPuiPKEz/Lp ccaC5G4DsSwlJoan/cjwIJDPRjpjTAlEUdmPx3B0uz5IUYD2YXDhhWBIJknI1H8QR4QufICWhjj 9okkUN3OE+wsRFlMl9huaL17HYk3shfe71xidbDyp5B6cKZnUvEX5j9VJdBg/wVev1FswWEkLEx JGc9Mul0EKR5v6RVrRtUllISQAN/QqLSlCN5UZaiDsIJVnqnPDihKIImkHzsshYasJt7ogU5/S+ jOiF6DLtbMDQGC8SdHcjgnuw== X-Received: by 2002:a05:620a:44c9:b0:8d4:629e:2e9a with SMTP id af79cd13be357-8dc3db3d27cmr45010785a.44.1775666430130; Wed, 08 Apr 2026 09:40:30 -0700 (PDT) Received: from localhost ([2603:7000:c00:3a00:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8d2a864b516sm1647543485a.37.2026.04.08.09.40.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Apr 2026 09:40:29 -0700 (PDT) Date: Wed, 8 Apr 2026 12:40:25 -0400 From: Johannes Weiner To: Mashiro Chen 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 Subject: Re: [PATCH] sched/psi: initialize *flags in psi_memstall_enter when PSI is disabled Message-ID: References: <20260405055044.554243-1-mashiro.chen@mailbox.org> <754f231c-f9a0-495d-b0d8-58f8c8e4dc12@mailbox.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <754f231c-f9a0-495d-b0d8-58f8c8e4dc12@mailbox.org> 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?