Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>, Hui Zhu <hui.zhu@linux.dev>
Cc: 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>, Kairui Song <kasong@tencent.com>,
	Qi Zheng <qi.zheng@linux.dev>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Barry Song <baohua@kernel.org>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Hui Zhu <zhuhui@kylinos.cn>
Subject: Re: [PATCH v6] mm: assert exclusive nid/zonenum bits at the page/folio access sites
Date: Mon, 29 Jun 2026 08:35:44 +0200	[thread overview]
Message-ID: <0404b7af-2785-4518-827f-9df0f30564d9@kernel.org> (raw)
In-Reply-To: <20260627213031.88e3bfb3489553afb1102399@linux-foundation.org>

On 6/28/26 06:30, Andrew Morton wrote:
> On Fri, 26 Jun 2026 10:06:29 +0800 Hui Zhu <hui.zhu@linux.dev> wrote:
> 
>> From: Hui Zhu <zhuhui@kylinos.cn>
>>
>> KCSAN reports a data race between page_to_nid()/folio_pgdat() reading
>> page->flags and folio_trylock()/folio_lock() concurrently doing
>> test_and_set_bit_lock(PG_locked, ...) on the same word, e.g.:
>>
>>   BUG: KCSAN: data-race in __lruvec_stat_mod_folio / shmem_get_folio_gfp
>>
>> The node id and zone id occupy fixed bit-ranges of page->flags that
>> are set once at page init and never modified afterwards, so they can
>> never overlap with the low PG_locked/PG_waiters bits touched by the
>> folio lock path.
>>
>> ASSERT_EXCLUSIVE_BITS(mdf.f, ...) inside memdesc_nid()/memdesc_zonenum()
>> used to check a by-value copy of the flags word, not the actual shared
>> page->flags/folio->flags being modified concurrently, so it didn't
>> reliably assert anything about the real race.
>>
>> For zonenum, move the assertion out of memdesc_zonenum() into
>> page_zonenum() and folio_zonenum(), where flags is dereferenced
>> directly from the page/folio.
>>
>> For nid, turn memdesc_nid() into a macro instead, so the mdf argument
>> is expanded as the caller's own flags expression
>> (PF_POISONED_CHECK(page)->flags or folio->flags) rather than copied
>> into a function parameter, letting ASSERT_EXCLUSIVE_BITS() check the
>> real page->flags/folio->flags directly.
>>
>> On CONFIG_NUMA=n, NODES_MASK is 0 and the old memdesc_nid() body
>> folded to a constant, so page->flags/folio->flags was never actually
>> read. ASSERT_EXCLUSIVE_BITS() is a real runtime check that can't be
>> folded away, so doing it unconditionally would add a pointless read
>> of page->flags/folio->flags and a check that can never fire. Keep
>> page_to_nid()/folio_nid() as plain "return 0" static inline stubs
>> under CONFIG_NUMA=n instead.
>>
> 
> Thanks for persisting with this.
> 
> ASSERT_EXCLUSIVE_BITS is defined in kcsan-checks.h and I'm not
> immediately seeing a reliable route by which mm.h and mmzone.h get to
> include that file.  I don't think kasan.h gives that to us,
> surprisingly.
> 
> Unless I've missed it, we're presently getting kcsan-checks.h thanks to
> good luck.  Let's not rely upon good luck ;)
> 
> 
> Also, Sashiko is saying stuff again.  Does it look legitimate?
> 	https://sashiko.dev/#/patchset/20260626020629.1042041-1-hui.zhu@linux.dev
> 

Let's see whether pass-by-reference as suggested in reply to v7 sorts this out.

-- 
Cheers,

David


      reply	other threads:[~2026-06-29  6:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26  2:06 [PATCH v6] mm: assert exclusive nid/zonenum bits at the page/folio access sites Hui Zhu
2026-06-28  4:30 ` Andrew Morton
2026-06-29  6:35   ` David Hildenbrand (Arm) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0404b7af-2785-4518-827f-9df0f30564d9@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=hui.zhu@linux.dev \
    --cc=kasong@tencent.com \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=qi.zheng@linux.dev \
    --cc=rppt@kernel.org \
    --cc=shakeel.butt@linux.dev \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=weixugc@google.com \
    --cc=yuanchu@google.com \
    --cc=zhuhui@kylinos.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox