From: sashiko-bot@kernel.org
To: xu.xin@linux.dev
Cc: acme@kernel.org, adrian.hunter@intel.com,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
akpm@linux-foundation.org, alexander.shishkin@linux.intel.com,
apopple@nvidia.com, baohua@kernel.org,
baolin.wang@linux.alibaba.com,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
byungchul@sk.com, chengming.zhou@linux.dev, david@kernel.org,
dev.jain@arm.com, gerald.schaefer@linux.ibm.com,
"Vasily Gorbik" <gor@linux.ibm.com>,
gourry@gourry.net, harry@kernel.org,
"Heiko Carstens" <hca@linux.ibm.com>,
irogers@google.com, james.clark@linaro.org, jannh@google.com,
jolsa@kernel.org, joshua.hahnjy@gmail.com, kas@kernel.org,
lance.yang@linux.dev, liam@infradead.org, linux-mm@kvack.org,
linux-s390@vger.kernel.org, ljs@kernel.org, mark.rutland@arm.com,
matthew.brost@intel.com, mhiramat@kernel.org, mhocko@suse.com,
mingo@redhat.com, namhyung@kernel.org, nico.pache@linux.dev,
oleg@redhat.com, peterz@infradead.org, riel@surriel.com,
rppt@kernel.org, ryan.roberts@arm.com, surenb@google.com,
svens@linux.ibm.com, usama.arif@linux.dev, vbabka@kernel.org,
ying.huang@linux.alibaba.com, ziy@nvidia.com,
xialonglong2025@163.com
Subject: Re: [PATCH v2 2/4] mm: make folio_walk_start()'s locking asserts scalable
Date: Tue, 03 Nov 2026 13:31:37 +0000 [thread overview]
Message-ID: <sashiko-outbox-195353@kernel.org> (raw)
In-Reply-To: <20261102132927.301921-1-xu.xin@linux.dev>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] mm: inaccurate commit message on write-locking in folio_walk_start()
- [Low] mm: folio_walk_start() duplicates vma_assert_stabilised() via walk_lock
- [Low] mm: missing kernel-doc and private placement for folio_walk::walk_lock
--
commit fbf030fed81b9a0de749bef1b3fa6307e8400b93
Author: Xu Xin <xu.xin@linux.dev>
mm: make folio_walk_start()'s locking asserts scalable
This commit adds a walk_lock member to struct folio_walk and updates
folio_walk_start() and its callers to specify locking assertion modes for
mmap_lock and per-VMA locks.
> mm: make folio_walk_start()'s locking asserts scalable
>
> Add an additional member 'walk_lock' to folio_walk to indicate
> locking requirements for the walk. Similar to commit 49b0638502da0
> ("mm: enable page walking API to lock vmas during the walk").
> But no change is made on any existing locking behavior,
> all existing folio_walk_start() callers are currently still
> under mmap_read_lock() protection.
>
> This change is prepared for the later patch to enable VMA locking
> asserts. folio_walk_start now operate under write-locked mmap_lock.
> With introduction of vma locks at the next patch, the vmas have to
> be locked as well during such walks to prevent concurrent page
> faults in these areas.
>
> No functional change intended.
>
> Signed-off-by: Xu Xin <xu.xin@linux.dev>
[Severity: Medium]
The second paragraph states that "folio_walk_start now operate under
write-locked mmap_lock" and that VMAs have to be locked during such walks.
Is this description accurate?
In mm/pagewalk.c, folio_walk_start() only expects PGWALK_RDLOCK or
PGWALK_VMA_RDLOCK_VERIFY and emits a warning on write-lock modes:
if (fw->walk_lock != PGWALK_RDLOCK && fw->walk_lock != PGWALK_VMA_RDLOCK_VERIFY)
WARN_ONCE(1, "walk_lock is not expected!\n");
Could the commit message be updated to reflect that folio_walk_start() only
verifies read-stabilized mmap or VMA locks?
[ ... ]
> diff --git a/include/linux/pagewalk.h b/include/linux/pagewalk.h
> index 1c397be0d092a..455428eaf1fc0 100644
> --- a/include/linux/pagewalk.h
> +++ b/include/linux/pagewalk.h
> @@ -184,6 +184,7 @@ struct folio_walk {
> };
> /* private */
> spinlock_t *ptl;
> + enum page_walk_lock walk_lock;
> };
[Severity: Low]
This isn't a bug, but adding walk_lock to struct folio_walk without a
@walk_lock entry in the kernel-doc comment above struct folio_walk triggers a
scripts/kernel-doc warning ("struct member 'walk_lock' not described in
'folio_walk'"), because the /* private */ comment does not use the
/* private: */ syntax recognized by kernel-doc.
Also, since callers of folio_walk_start() are required to initialize
fw.walk_lock before the call, should walk_lock be placed in the public
section of struct folio_walk rather than under /* private */, and should the
kernel-doc for folio_walk_start() in mm/pagewalk.c (which currently states
"@fw: filled with information on success." and "The mmap lock must be held in
read mode.") be updated to match?
[ ... ]
> diff --git a/mm/pagewalk.c b/mm/pagewalk.c
> index e6493bbe6919e..7d85289fcb875 100644
> --- a/mm/pagewalk.c
> +++ b/mm/pagewalk.c
> @@ -910,7 +910,15 @@ struct folio *folio_walk_start(struct folio_walk *fw,
> pgd_t *pgdp;
> p4d_t *p4dp;
>
> - mmap_assert_locked(vma->vm_mm);
> + /*
> + * Other locking modes except for mmap or vma read locking are not
> + * expected.
> + */
> + if (fw->walk_lock != PGWALK_RDLOCK && fw->walk_lock != PGWALK_VMA_RDLOCK_VERIFY)
> + WARN_ONCE(1, "walk_lock is not expected!\n");
> + process_mm_walk_lock(vma->vm_mm, fw->walk_lock);
> + process_vma_walk_lock(vma, fw->walk_lock);
[Severity: Low]
If a caller passes an unexpected walk_lock value (such as PGWALK_WRLOCK) or
leaves struct folio_walk uninitialized, folio_walk_start() triggers
WARN_ONCE() here, but then still calls process_mm_walk_lock() and
process_vma_walk_lock(), which for PGWALK_WRLOCK will call
vma_start_write(vma).
More broadly, since folio_walk_start() only permits mmap or VMA read-lock
verification, could folio_walk_start() simply call vma_assert_stabilised(vma)
from include/linux/mmap_lock.h instead of adding walk_lock to struct
folio_walk and requiring every caller to initialize it:
static inline void vma_assert_stabilised(const struct vm_area_struct *vma)
{
if (IS_ENABLED(CONFIG_LOCKDEP)) {
if (lockdep_is_held(&vma->vm_mm->mmap_lock))
return;
} else {
if (rwsem_is_locked(&vma->vm_mm->mmap_lock))
return;
}
vma_assert_locked(vma);
}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261102132416.300084-1-xu.xin@linux.dev?part=2
next prev parent reply other threads:[~2026-11-03 13:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 13:24 [PATCH v2 0/4] mm/ksm: use per-VMA locking to reduce mmap_lock contention xu.xin
2026-11-02 13:28 ` [PATCH v2 1/4] mm/pagewalk: delete the unused member xu.xin
2026-11-02 13:29 ` [PATCH v2 2/4] mm: make folio_walk_start()'s locking asserts scalable xu.xin
2026-11-03 13:31 ` sashiko-bot [this message]
2026-11-02 13:29 ` [PATCH v2 3/4] mm/ksm: make break_ksm() more scalable xu.xin
2026-11-03 13:31 ` sashiko-bot
2026-11-02 13:31 ` [PATCH v2 4/4] ksm: add find_mergeable_vma_locked() to use per-VMA locking xu.xin
2026-11-03 13:31 ` sashiko-bot
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=sashiko-outbox-195353@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=apopple@nvidia.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=borntraeger@linux.ibm.com \
--cc=byungchul@sk.com \
--cc=chengming.zhou@linux.dev \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=gourry@gourry.net \
--cc=harry@kernel.org \
--cc=hca@linux.ibm.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jannh@google.com \
--cc=jolsa@kernel.org \
--cc=joshua.hahnjy@gmail.com \
--cc=kas@kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=mark.rutland@arm.com \
--cc=matthew.brost@intel.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=nico.pache@linux.dev \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=surenb@google.com \
--cc=svens@linux.ibm.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=xialonglong2025@163.com \
--cc=xu.xin@linux.dev \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
/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