linux-kernel - Re: [PATCH v3 3/3] mm/vmscan: don't demote if there is not enough free memory in the lower memory tier

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXkfBF5bdnTZ7t7e@gourry-fedora-PF4VCD3F>
Date: Tue, 27 Jan 2026 15:24:36 -0500
From: Gregory Price <gourry@...rry.net>
To: Akinobu Mita <akinobu.mita@...il.com>
Cc: linux-cxl@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, akpm@...ux-foundation.org,
	axelrasmussen@...gle.com, yuanchu@...gle.com, weixugc@...gle.com,
	hannes@...xchg.org, david@...nel.org, mhocko@...nel.org,
	zhengqi.arch@...edance.com, shakeel.butt@...ux.dev,
	lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, vbabka@...e.cz,
	rppt@...nel.org, surenb@...gle.com, bingjiao@...gle.com
Subject: Re: [PATCH v3 3/3] mm/vmscan: don't demote if there is not enough
 free memory in the lower memory tier

On Sat, Jan 10, 2026 at 10:55:02PM +0900, Akinobu Mita wrote:
> 2026年1月10日(土) 1:08 Gregory Price <gourry@...rry.net>:
> >
> > > +     for_each_node_mask(nid, allowed_mask) {
> > > +             int z;
> > > +             struct zone *zone;
> > > +             struct pglist_data *pgdat = NODE_DATA(nid);
> > > +
> > > +             for_each_managed_zone_pgdat(zone, pgdat, z, MAX_NR_ZONES - 1) {
> > > +                     if (zone_watermark_ok(zone, 0, min_wmark_pages(zone),
> > > +                                             ZONE_MOVABLE, 0))
> >
> > Why does this only check zone movable?
> 
> Here, zone_watermark_ok() checks the free memory for all zones from 0 to
> MAX_NR_ZONES - 1.
> There is no strong reason to pass ZONE_MOVABLE as the highest_zoneidx
> argument every time zone_watermark_ok() is called; I can change it if an
> appropriate value is found.
> In v1, highest_zoneidx was "sc ? sc->reclaim_idx : MAX_NR_ZONES - 1"
> 
> > Also, would this also limit pressure-signal to invoke reclaim when
> > there is still swap space available?  Should demotion not be a pressure
> > source for triggering harder reclaim?
> 
> Since can_reclaim_anon_pages() checks whether there is free space on the swap
> device before checking with can_demote(), I think the negative impact of this
> change will be small. However, since I have not been able to confirm the
> behavior when a swap device is available, I would like to correctly understand
> the impact.

Something else is going on here

See demote_folio_list and alloc_demote_folio

static unsigned int demote_folio_list(struct list_head *demote_folios,
                                      struct pglist_data *pgdat,
                                      struct mem_cgroup *memcg)
{
        struct migration_target_control mtc = {
                 */
                .gfp_mask = (GFP_HIGHUSER_MOVABLE & ~__GFP_RECLAIM) |
                        __GFP_NOMEMALLOC | GFP_NOWAIT,
        };
}

static struct folio *alloc_demote_folio(struct folio *src,
                unsigned long private)
{
	/* Only attempt to demote to the preferred node */
        mtc->nmask = NULL;
        mtc->gfp_mask |= __GFP_THISNODE;
        dst = alloc_migration_target(src, (unsigned long)mtc);
        if (dst)
                return dst;

	/* Now attempt to demote to any node in the lower tier */
        mtc->gfp_mask &= ~__GFP_THISNODE;
        mtc->nmask = allowed_mask;
        return alloc_migration_target(src, (unsigned long)mtc);
}


/*
* %__GFP_RECLAIM is shorthand to allow/forbid both direct and kswapd reclaim.
*/


You basically shouldn't be hitting any reclaim behavior at all, and if
the target nodes are actually under various watermarks, you should be
getting allocation failures and quick-outs from the demotion logic.

i.e. you should be seeing OOM happen

When I dug in far enough I found this:

static struct folio *alloc_demote_folio(struct folio *src,
                unsigned long private)
{
...
        dst = alloc_migration_target(src, (unsigned long)mtc);
}

struct folio *alloc_migration_target(struct folio *src, unsigned long private)
{
        
...
        if (folio_test_hugetlb(src)) {
                struct hstate *h = folio_hstate(src);

                gfp_mask = htlb_modify_alloc_mask(h, gfp_mask);
                return alloc_hugetlb_folio_nodemask(h, nid, ...)
	}
}

static inline gfp_t htlb_modify_alloc_mask(struct hstate *h, gfp_t gfp_mask)
{
        gfp_t modified_mask = htlb_alloc_mask(h);

        /* Some callers might want to enforce node */
        modified_mask |= (gfp_mask & __GFP_THISNODE);

        modified_mask |= (gfp_mask & __GFP_NOWARN);

        return modified_mask;
}

/* Movability of hugepages depends on migration support. */
static inline gfp_t htlb_alloc_mask(struct hstate *h)
{
        gfp_t gfp = __GFP_COMP | __GFP_NOWARN;

        gfp |= hugepage_movable_supported(h) ? GFP_HIGHUSER_MOVABLE : GFP_HIGHUSER;

        return gfp;
}

#define GFP_USER        (__GFP_RECLAIM | __GFP_IO | __GFP_FS | __GFP_HARDWALL)
#define GFP_HIGHUSER    (GFP_USER | __GFP_HIGHMEM)
#define GFP_HIGHUSER_MOVABLE    (GFP_HIGHUSER | __GFP_MOVABLE | __GFP_SKIP_KASAN)


If we try to move a hugepage, we start including __GFP_RECLAIM again -
regardless of whether HIGHUSER_MOVABLE or HIGHUSER is used.


Any chance you are using hugetlb on this system?  This looks like a
clear bug, but it may not be what you're experiencing.

~Gregory