From: Bing Jiao <bingjiao@google.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Qi Zheng <zhengqi.arch@bytedance.com>,
Shakeel Butt <shakeel.butt@linux.dev>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/vmscan: restore allowed mask in alloc_demote_folio()
Date: Mon, 2 Mar 2026 19:18:26 +0000 [thread overview]
Message-ID: <aaXigujRj2llz1xc@google.com> (raw)
In-Reply-To: <98480065-e988-477f-ba37-f9521e4aecbb@kernel.org>
On Mon, Mar 02, 2026 at 09:00:07AM +0100, David Hildenbrand (Arm) wrote:
> On 3/2/26 08:03, Bing Jiao wrote:
> > In alloc_demote_folio(), mtc->nmask is set to NULL for the first
> > allocation. If that succeeds, it returns without restoring mtc->nmask
> > to allowed_mask. For subsequent allocations from the migrate_pages()
> > batch, mtc->nmask will be NULL. If the target node then becomes full,
> > the fallback allocation will use nmask = NULL, allocating from any
> > node allowed by the task cpuset, which for kswapd is all nodes.
> >
> > To address this issue, restore the mtc->nmask to its original allowed
> > nodemask after the first allocation.
> >
>
> That would be
>
> Fixes: 320080272892 ("mm/demotion: demote pages according to allocation fallback order")
>
> ?
Thanks for pointing it out. Will add it in the new patch.
> > Signed-off-by: Bing Jiao <bingjiao@google.com>
> > ---
> > mm/vmscan.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index cbffc0a27824..b42abd17aee7 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -985,11 +985,11 @@ static struct folio *alloc_demote_folio(struct folio *src,
> > mtc->nmask = NULL;
> > mtc->gfp_mask |= __GFP_THISNODE;
> > dst = alloc_migration_target(src, (unsigned long)mtc);
> > + mtc->nmask = allowed_mask;
> > if (dst)
> > return dst;
> >
> > mtc->gfp_mask &= ~__GFP_THISNODE;
> > - mtc->nmask = allowed_mask;
> >
> > return alloc_migration_target(src, (unsigned long)mtc);
> > }
> > --
> > 2.53.0.473.g4a7958ca14-goog
> >
>
> Maybe we should just not touch the original mtc?
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index de62225b381a..f07716e5389e 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -985,9 +985,9 @@ static void folio_check_dirty_writeback(struct folio *folio,
> static struct folio *alloc_demote_folio(struct folio *src,
> unsigned long private)
> {
> + struct migration_target_control *mtc, target_nid_mtc;
> struct folio *dst;
> nodemask_t *allowed_mask;
> - struct migration_target_control *mtc;
>
> mtc = (struct migration_target_control *)private;
>
> @@ -1001,15 +1001,12 @@ static struct folio *alloc_demote_folio(struct folio *src,
> * a demotion of cold pages from the target memtier. This can result
> * in the kernel placing hot pages in slower(lower) memory tiers.
> */
> - mtc->nmask = NULL;
> - mtc->gfp_mask |= __GFP_THISNODE;
> - dst = alloc_migration_target(src, (unsigned long)mtc);
> + target_nid_mtc = *mtc;
> + target_nid_mtc.nmask = NULL;
> + target_nid_mtc.gfp_mask |= __GFP_THISNODE;
> + dst = alloc_migration_target(src, (unsigned long)&target_nid_mtc);
> if (dst)
> return dst;
> -
> - mtc->gfp_mask &= ~__GFP_THISNODE;
> - mtc->nmask = allowed_mask;
> -
> return alloc_migration_target(src, (unsigned long)mtc);
> }
>
>
>
> --
> Cheers,
>
> David
Thank you for the suggestion, David.
I agree that not touching the original mtc is a better. It makes
the distinction between the two allocation attempts much clearer
and avoids the side-effect bug. Will update it then.
Best,
Bing
next prev parent reply other threads:[~2026-03-02 19:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-02 7:03 [PATCH] mm/vmscan: restore allowed mask in alloc_demote_folio() Bing Jiao
2026-03-02 8:00 ` David Hildenbrand (Arm)
2026-03-02 19:18 ` Bing Jiao [this message]
2026-03-03 5:25 ` [PATCH v2] mm/vmscan: fix unintended mtc->nmask mutation " Bing Jiao
2026-03-03 9:01 ` David Hildenbrand (Arm)
2026-03-03 9:45 ` Lorenzo Stoakes
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=aaXigujRj2llz1xc@google.com \
--to=bingjiao@google.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=weixugc@google.com \
--cc=yuanchu@google.com \
--cc=zhengqi.arch@bytedance.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 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.