DAMON development mailing list
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "SJ Park" <sj@kernel.org>
Cc: damon@lists.linux.dev
Subject: Re: [PATCH 6.6.y] mm/damon/paddr: drop last same folio access check reuse optimization
Date: Wed, 09 Sep 2026 05:56:12 +0000	[thread overview]
Message-ID: <20260909055612.D31801F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260909054545.256743-1-sj@kernel.org>

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

Pre-existing issues:
- [High] Physical address sampling and PFN iterations fail for large folios because `damon_get_folio` explicitly rejects tail pages.
--

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

mm/damon/paddr: drop last same folio access check reuse optimization

This commit drops the optimization that reuses the previous physical address
access check if the region falls within the last checked folio. The author
removes it in favor of code simplicity, noting it can race when multiple
kdamonds are used.

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

> diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c
> index 909db25efb35e..fe481ae64f37e 100644
> --- a/mm/damon/paddr.c
> +++ b/mm/damon/paddr.c
[ ... ]
> @@ -111,7 +111,7 @@ static bool __damon_pa_young(struct folio *folio, struct vm_area_struct *vma,
>  	return *accessed == false;
>  }
>  
> -static bool damon_pa_young(unsigned long paddr, unsigned long *folio_sz)
> +static bool damon_pa_young(unsigned long paddr)
>  {
>  	struct folio *folio = damon_get_folio(PHYS_PFN(paddr));
>  	bool accessed = false;

[Severity: High]
This isn't a bug introduced by this patch, but does physical address sampling
fail for large folios because damon_get_folio() rejects tail pages?

In damon_pa_young(), the sampled physical address is passed to
damon_get_folio() via PHYS_PFN(paddr). For large folios, this randomly
sampled address is extremely likely to fall on a tail page. Since
damon_get_folio() explicitly returns NULL for tail pages:

mm/damon/ops-common.c:damon_get_folio() {
    ...
    if (!page || PageTail(page))
        return NULL;
    ...
}

Does this mean DAMON silently ignores large folios for physical address
monitoring? This same tail page rejection seems to cause the unconditional
PAGE_SIZE stepping in damon_pa_pageout() and
damon_pa_mark_accessed_or_deactivate() to skip entire large folios if the
region boundaries start on a tail page.

While this wasn't introduced by this patch, dropping the last-folio-size
cache here removes the only mechanism that might have partially masked this
flaw for randomly sampled addresses that happened to hit a head page.

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

  reply	other threads:[~2026-09-09  5:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2026090853-disparity-bazooka-4747@gregkh>
2026-09-09  5:45 ` [PATCH 6.6.y] mm/damon/paddr: drop last same folio access check reuse optimization SJ Park
2026-09-09  5:56   ` sashiko-bot [this message]
2026-09-09 20:26   ` Sasha Levin

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=20260909055612.D31801F00A3D@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox