All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "SJ Park" <sj@kernel.org>
Cc: damon@lists.linux.dev
Subject: Re: [PATCH 7.2.y] mm/damon/vaddr: drop last same folio access check optimization
Date: Wed, 09 Sep 2026 06:03:21 +0000	[thread overview]
Message-ID: <20260909060322.3B47E1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260909055319.263738-1-sj@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] DAMOS PTE-level PMD iteration incorrectly advances past unrelated memory when encountering large folio tail pages.
--

commit d786b1179a857b410a9db73cdc4ee0d7bdcbede5
Author: SJ Park <sj@kernel.org>

mm/damon/vaddr: drop last same folio access check optimization
    
This commit drops the last same folio access check optimization in DAMON.
The optimization can race when multiple kdamonds are running, and its
impact is doubtful.

Link: https://lore.kernel.org/20260715031002.108504-4-sj@kernel.org
Link: https://lore.kernel.org/20260621204050.10993-1-sj@kernel.org [1]

> diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
> index 2c1c1952c008d..404785128ffd7 100644
> --- a/mm/damon/vaddr.c
> +++ b/mm/damon/vaddr.c
[ ... ]

[Severity: High]
This is a pre-existing issue, but does this code incorrectly advance past
unrelated memory when encountering large folio tail pages?

Looking at damos_va_migrate_pmd_entry() and damos_va_stat_pmd_entry() in
mm/damon/vaddr.c, the PTE iterator unconditionally advances by the full folio
size:

mm/damon/vaddr.c:damos_va_migrate_pmd_entry() {
    ...
	for (; addr < next; pte += nr, addr += nr * PAGE_SIZE) {
		nr = 1;
		ptent = ptep_get(pte);

		if (pte_none(ptent) || !pte_present(ptent))
			continue;
		folio = vm_normal_folio(walk->vma, addr, ptent);
    ...
		damos_va_migrate_dests_add(folio, walk->vma, addr, dests,
				migration_lists);
		nr = folio_nr_pages(folio);
	}
    ...
}

If the loop encounters a PTE pointing to a tail page of a large folio,
folio_nr_pages(folio) returns the size of the entire large folio. Because the
current PTE does not point to the head of the folio, advancing pte and
addr by the full folio size will overshoot into unrelated page table
entries, skipping memory regions during migration and stats scanning.

Could this lead to incorrect functional behavior where unrelated memory
regions are silently skipped by DAMOS actions?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909055319.263738-1-sj@kernel.org?part=1

      reply	other threads:[~2026-09-09  6:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08 12:52 FAILED: patch "[PATCH] mm/damon/vaddr: drop last same folio access check" failed to apply to 7.2-stable tree gregkh
2026-09-09  5:53 ` [PATCH 7.2.y] mm/damon/vaddr: drop last same folio access check optimization SJ Park
2026-09-09  6:03   ` sashiko-bot [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=20260909060322.3B47E1F00A3D@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=damon@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sj@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.