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 13C38376A17 for ; Tue, 23 Jun 2026 10:25:09 +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=1782210311; cv=none; b=Ln+bcYJwz6Nh3sqTGdBDA8O35KbTRUKvKCYJPFzOSrk1LSKK9PScNODPjEquOb2BwpjwKdmLkzxQKRui94snPcsjNf4UHPXQccu6B+0aFtUlKVA2KbXL+0gj16QyZHVdfQXptiwlFH0XT7xGtNyEdXV8o5hk+fY4dTy1EctAaT4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782210311; c=relaxed/simple; bh=8ji2g7AO0/kpa9xOFKs1rGh0ofG2tr8i9wSZNzpQnbY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PX3F/Gxe4YcdLpShlKET9fQw6x9z7oPH47mMFd12nCjHE3bPzsaDdeGJuCFGoh5+b4saopk95SckkcqHcNhjXXHyw0iWvI/tmJgjjf5HJRu4As6kIPKtJknVYHhG6h6rOqECetMsuwfpQo2GHUTb9ZTMfl+l+ZTOAWeHoAIoYSg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E4KivSwy; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="E4KivSwy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2AAE21F000E9; Tue, 23 Jun 2026 10:25:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782210309; bh=QuwqPl/DdRExnnCu9OGScQ5Xmc6WliItT49dCHtwxdw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=E4KivSwyGZFxXffDk/Vt3Px8vA1CbyhPHDP47lNNJ7szT26VvcSc7qGCtrBR90H/k rKJn+oEhr43yZ92MkI6SLFEI7zny0/e4YijR25E1lI/JuBgEKP99aBDpCOALVN+iXx c+bPYmiBSofBu9XN/II1kzckbdcDV3Hg7OsDNw/xJ3ra54hJ9QVWhoJntkXyoFNPt0 bD8plIrLTi/QiYw9bTycvJDyNnFdcIXHuedBb1+aTsqsCL/D39Jv62cYU9pj1ARwoj 2KvD/zpvrHSMriP88SRSH7NefbWyChEQUZHOALvxF6jf83DGmejAt9chUxhNWHXYpz izbpybBP14RFw== Date: Tue, 23 Jun 2026 11:25:02 +0100 From: Lorenzo Stoakes To: "David Hildenbrand (Arm)" Cc: Hui Zhu , Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Hui Zhu Subject: Re: [PATCH] mm: avoid KCSAN false positive in page_to_nid() Message-ID: References: <20260623074157.578113-1-hui.zhu@linux.dev> <97f2c4ad-c302-424d-a7c8-fdfa0fc0d811@kernel.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=us-ascii Content-Disposition: inline In-Reply-To: <97f2c4ad-c302-424d-a7c8-fdfa0fc0d811@kernel.org> On Tue, Jun 23, 2026 at 09:59:45AM +0200, David Hildenbrand (Arm) wrote: > On 6/23/26 09:41, Hui Zhu wrote: > > From: Hui Zhu > > > > KCSAN reports a data race between page_to_nid() reading page->flags > > and folio_trylock()/folio_lock() doing test_and_set_bit_lock(PG_locked, > > ...) on the same word from another CPU, e.g.: > > > > BUG: KCSAN: data-race in __lruvec_stat_mod_folio / shmem_get_folio_gfp > > > > The node id occupies a fixed, high bit-range of page->flags that is > > set once when the page is initialized and never modified afterwards, > > so it can never overlap with the low PG_locked/PG_waiters bits touched > > by the folio lock path. The race is therefore harmless: page_to_nid() > > always returns a consistent value regardless of how the read > > interleaves with the lock bit ops. > > > > Wrap the flags read with data_race() to tell KCSAN this race is > > intentional and benign, consistent with how page->page_type is > > already annotated for similar packed-field accesses. > > > > Signed-off-by: Hui Zhu How did you discover this? A syzbot report? If so please include Reported-by, Closes tags. > > --- > > include/linux/mm.h | 9 ++++++++- > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index 485df9c2dbdd..122d3b39369f 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -2296,7 +2296,14 @@ static inline int memdesc_nid(memdesc_flags_t mdf) > > > > static inline int page_to_nid(const struct page *page) > > { > > - return memdesc_nid(PF_POISONED_CHECK(page)->flags); > > + /* > > + * The node id occupies a fixed high bit-range of page->flags > > + * that is set once at page init and never changed afterwards. > > + * It cannot overlap with the low PG_locked/PG_waiters bits > > + * that folio_lock()/folio_unlock() concurrently update, so > > + * this data race is benign. > > + */ > > Do we really need this excessive comment? Agreed, just delete it. For a trivial benign data race it's a bit much, and the commit message can cover it off for those who are curious. > > > + return memdesc_nid(data_race(PF_POISONED_CHECK(page)->flags)); > > In memdesc_zonenum() we use ASSERT_EXCLUSIVE_BITS. > > Can we do the same here inside memdesc_nid? Also agreed > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 69daeeab7fe8f..76d3bb54be844 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -2290,6 +2290,7 @@ int memdesc_nid(memdesc_flags_t mdf); > #else > static inline int memdesc_nid(memdesc_flags_t mdf) > { > + ASSERT_EXCLUSIVE_BITS(mdf.f, NODES_MASK << NODES_PGSHIFT); > return (mdf.f >> NODES_PGSHIFT) & NODES_MASK; > } > #endif > > > -- > Cheers, > > David Thanks, Lorenzo