From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18])
	(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 5BA923A2E36
	for <linux-kernel@vger.kernel.org>; Thu, 25 Jun 2026 01:58:26 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1782352709; cv=none; b=XxnuFcgJVA7/eMFQ/fSA4RQVHVTmxfzr9x4655L+DPhxQYOZRTXZSn45Lhy+2Kc+cHdct69z+JJ6Vu72HIp0c487je5lz0Kz3jFNFUc0pwohhoWc0+7XoXhQD20kSw/91P/eQsyYoMRlrIgzj0mfLLRGsX1pB+LGG7Y2QIZHPu8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1782352709; c=relaxed/simple;
	bh=lvnlBwRE8k8DP+r6SKTw71Wp68E1cswTpPBYFQXbGRc=;
	h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References:
	 Mime-Version:Content-Type; b=pnkJE0TQqPggm+DdaHdkWQUT6FBvqenDl/9jR/MCgeR8tZviMtbMYeAlXj75idtH8NvC/6DizgoE50HndOeISGFZ4FvJBMBE0hnXyl9xrUqnrtynZNd+daMQh5wCswOLOBJj0u8l2y7k+RjGst+n0DOSa2JqAjAdYCmWxs+cNuc=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=lVNMmqT0; arc=none smtp.client-ip=100.103.45.18
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="lVNMmqT0"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 480391F000E9;
	Thu, 25 Jun 2026 01:58:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linux-foundation.org; s=korg; t=1782352705;
	bh=wQICN80wmISSO42bSj3qCDWDRspRJwLjGgDPUT3kM1A=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References;
	b=lVNMmqT0XJQ/hWnrAroEdYQPCRMflmMYlJJ87gyKUWoEujRoXPoME7VsQwMe6fc35
	 lLoN0jpRo1RJBMuBNT7Hh4TgVEx7h9mwyOH/E/6xvZ6Mm8vcofKSs37oFb6sjLfToq
	 qIDtHT4Da7EKLM7gL2MOpteO0AGVCkumo3Ts9UMs=
Date: Wed, 24 Jun 2026 18:58:24 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: "Hui Zhu" <hui.zhu@linux.dev>
Cc: "David Hildenbrand" <david@kernel.org>, "Lorenzo Stoakes"
 <ljs@kernel.org>, "Liam R. Howlett" <liam@infradead.org>, "Vlastimil Babka"
 <vbabka@kernel.org>, "Mike Rapoport" <rppt@kernel.org>,
 "Suren Baghdasaryan" <surenb@google.com>, "Michal Hocko" <mhocko@suse.com>,
 linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Hui Zhu"
 <zhuhui@kylinos.cn>
Subject: Re: [PATCH v2] mm: avoid KCSAN false positive in memdesc_nid()
Message-Id: <20260624185824.f052e7b8f97ee20794e476aa@linux-foundation.org>
In-Reply-To: <20bd8bbbd5a8cc52d267f550fc0314cd0d81a223@linux.dev>
References: <20260623084432.701120-1-hui.zhu@linux.dev>
	<20260624140104.eacc15e291eec123bc7b3349@linux-foundation.org>
	<20bd8bbbd5a8cc52d267f550fc0314cd0d81a223@linux.dev>
X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 25 Jun 2026 01:32:49 +0000 "Hui Zhu" <hui.zhu@linux.dev> wrote:

> Good catch. ASSERT_EXCLUSIVE_BITS(mdf.f, ...) is checking a by-value
> copy of the flags word inside memdesc_nid(), not the actual shared
> page->flags/folio->flags being modified by folio_trylock(). Whatever
> made it appear to suppress the KCSAN report is likely an artifact of
> inlining/codegen (kcsan_atomic_next() happening to land on the real
> load after inlining), not a principled fix - so Sashiko's pass is
> not reassuring here.

Yeah, I was wondering if the inlining accidentally gave the macro the
correct thing.  Which seems wrong - an inlined function should treat an
incoming arg purely as a local thing.  Maybe we fooled the compiler.

> I'll move the assertion to where the real dereference happens (at
> the page_to_nid()/folio_nid() call sites) instead of inside the
> by-value helper. This probably also applies to the existing
> memdesc_zonenum() pattern - is that one actually verified to work,
> or does it have the same issue?

I assume the memdesc_zonenum() code worked, for the same (poorly
understood) reason as did your patch.

Yes, moving this into the sites where we officially have access to the
shared storage seems the right approach.