All of lore.kernel.org
 help / color / mirror / Atom feed
From: SJ Park <sj@kernel.org>
To: sashiko-bot@kernel.org
Cc: SJ Park <sj@kernel.org>, damon@lists.linux.dev
Subject: Re: [RFC PATCH v1.1 3/9] mm/damon/paddr: respect folio end for DAMOS_STAT
Date: Sun,  2 Aug 2026 10:43:38 -0700	[thread overview]
Message-ID: <20260802174340.1587-1-sj@kernel.org> (raw)
In-Reply-To: <20260802163458.108881F000E9@smtp.kernel.org>

On Sun, 02 Aug 2026 16:34:57 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] This problem wasn't introduced by this patch, but the patch provides an incomplete fix for an address advancement logic bug. While it corrects the `addr += folio_size(folio)` issue in `damon_pa_stat()` to correctly align the next address to the end of the large folio, it fails to apply the exact same fix to `damon_pa_pageout()`, `damon_pa_de_activate()`, and `damon_pa_migrate()`.
> --
> 
> --- Patch [3]: [RFC PATCH v1.1 3/9] mm/damon/paddr: respect folio end for DAMOS_STAT ---
> commit 99e0c032eda9c903df8d327aa77b989129d9b193
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/paddr: respect folio end for DAMOS_STAT
> 
> This commit fixes the address advancement in damon_pa_stat(). When a region
> starts in the middle of a large folio, it now properly aligns to the start of
> the next folio instead of simply adding the folio size and overshooting.
> 
> > diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c
> > --- a/mm/damon/paddr.c
> > +++ b/mm/damon/paddr.c
> > @@ -379,7 +379,7 @@ static unsigned long damon_pa_stat(struct damon_region *r,
> >  
> >  		if (!damos_pa_filter_out(s, folio))
> >  			*sz_filter_passed += folio_size(folio) / addr_unit;
> > -		addr += folio_size(folio);
> > +		addr = PFN_PHYS(folio_pfn(folio)) + folio_size(folio);
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but does the same address
> advancement logic regression still exist in other DAMON actions?
> 
> While you fixed the overshoot behavior here in damon_pa_stat(), it looks like
> damon_pa_pageout(), damon_pa_de_activate(), and damon_pa_migrate() in
> mm/damon/paddr.c might still be using the flawed logic.
> 
> For example, in damon_pa_pageout():
> 
>     put_folio:
> 		addr += folio_size(folio);
> 		folio_put(folio);
> 
> Could this cause DAMON actions to silently skip sections of valid memory
> if a region starts in the middle of a large folio?

A later patch of this series fix that.

> 
> >  		folio_put(folio);
> >  	}
> >  	s->last_applied = folio;
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260802162631.90304-1-sj@kernel.org?part=3
> 


Thanks,
SJ

  reply	other threads:[~2026-08-02 17:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-02 16:26 [RFC PATCH v1.1 0/9] mm/damon: fix DAMOS bugs in core, paddr and vaddr SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 1/9] mm/damon/core: skip applying scheme if region split for quota fails SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 2/9] mm/damon/core: initialize damos_quota_goal->last_psi_total SJ Park
2026-08-02 16:43   ` sashiko-bot
2026-08-02 17:41     ` SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 3/9] mm/damon/paddr: respect folio end for DAMOS_STAT SJ Park
2026-08-02 16:34   ` sashiko-bot
2026-08-02 17:43     ` SJ Park [this message]
2026-08-02 16:26 ` [RFC PATCH v1.1 4/9] mm/damon/paddr: respect folio end for DAMOS actions except STAT SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 5/9] mm/damon/vaddr: respect folio end for DAMOS_STAT SJ Park
2026-08-02 16:36   ` sashiko-bot
2026-08-02 17:45     ` SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 6/9] mm/damon/vaddr: respect folio end for DAMOS_MIGRATE_{HOT,COLD} SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 7/9] mm/damon/core: handle extreme memory state in damon_get_node_mem_bp() SJ Park
2026-08-02 16:35   ` sashiko-bot
2026-08-02 17:49     ` SJ Park
2026-08-02 17:59       ` SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 8/9] mm/damon/core: handle extreme memory state in get_node_memcg_used_bp() SJ Park
2026-08-02 16:38   ` sashiko-bot
2026-08-02 17:51     ` SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 9/9] mm/damon/core: handle extreme memory state in get_in_active_mem_bp() SJ Park
2026-08-02 16:51   ` sashiko-bot
2026-08-02 17:51     ` SJ Park

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=20260802174340.1587-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=damon@lists.linux.dev \
    --cc=sashiko-bot@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.