Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
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


  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