stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Muchun Song <muchun.song@linux.dev>
To: Hongfu Li <hongfu.li@linux.dev>
Cc: Oscar Salvador <osalvador@suse.de>,
	David Hildenbrand <david@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Kees Cook <kees@kernel.org>,
	Colin Ian King <colin.i.king@gmail.com>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Mina Almasry <almasrymina@google.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Hongfu Li <lihongfu@kylinos.cn>,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/2] mm/hugetlb_cgroup: move per-node usage on cross node migration
Date: Thu, 17 Sep 2026 13:58:11 +0800	[thread overview]
Message-ID: <E35A1286-33DF-4B54-8338-888EE28BFD06@linux.dev> (raw)
In-Reply-To: <20260916-for-hugetlb-charge-v1-1-70fb708b2e4a@kylinos.cn>



> On Sep 16, 2026, at 16:30, Hongfu Li <hongfu.li@linux.dev> wrote:
> 
> From: Hongfu Li <lihongfu@kylinos.cn>
> 
> hugetlb.<size>.numa_stat uses folio_nid() to account usage in
> __hugetlb_cgroup_commit_charge() and __hugetlb_cgroup_uncharge_folio().
> hugetlb_cgroup_migrate() only moves hugetlb_cgroup pointers, leaving
> per-node usage behind on the source node during cross-node migration.
> 
> When the migrated folio gets uncharged, we subtract usage from the
> destination node counter. This creates stale usage on the source node
> and unsigned long counter underflow on the destination node.
> The hugetlb.<size>.numa_stat interface exposes these incorrect per-node
> usage values to userspace.
> 
> Add a hugetlb_cgroup_move_usage() helper which moves the usage from the
> old node to the new node, and call it from hugetlb_cgroup_migrate().
> 
> Fixes: f47761999052 ("hugetlb: add hugetlb.*.numa_stat file")
> Cc: stable@vger.kernel.org
> Signed-off-by: Hongfu Li <lihongfu@kylinos.cn>
> ---
> mm/hugetlb_cgroup.c | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> 
> diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
> index ecb6e0b7819a..1040406e7e1d 100644
> --- a/mm/hugetlb_cgroup.c
> +++ b/mm/hugetlb_cgroup.c
> @@ -179,6 +179,34 @@ static void hugetlb_cgroup_css_free(struct cgroup_subsys_state *css)
> hugetlb_cgroup_free(hugetlb_cgroup_from_css(css));
> }
> 
> +static void hugetlb_cgroup_move_usage(struct hugetlb_cgroup *from,
> + 				     struct hugetlb_cgroup *to,
> + 				     struct folio *from_folio,
> +  			             struct folio *to_folio)
> +{
> + 	int idx = hstate_index(folio_hstate(from_folio));
> + 	unsigned long nr_pages = folio_nr_pages(from_folio);
> + 	int from_nid = folio_nid(from_folio);
> + 	int to_nid = folio_nid(to_folio);
> + 	unsigned long usage;
> +
> + 	lockdep_assert_held(&hugetlb_lock);
> +
> + 	if (!from || !to)
> + 		return;
> +
> + 	if (from == to && from_nid == to_nid)
> + 		return;
> +
> + 	usage = READ_ONCE(from->nodeinfo[from_nid]->usage[idx]);

READ_ONCE is unnecessary because there is no concurrent writer.

> + 	if (WARN_ON_ONCE(usage < nr_pages))
> + 		return;
> + 	WRITE_ONCE(from->nodeinfo[from_nid]->usage[idx], usage - nr_pages);
> +
> + 	usage = READ_ONCE(to->nodeinfo[to_nid]->usage[idx]);

Same here.

> + 	WRITE_ONCE(to->nodeinfo[to_nid]->usage[idx], usage + nr_pages);
> +}
> +
> /*
>  * Should be called with hugetlb_lock held.
>  * Since we are holding hugetlb_lock, pages cannot get moved from
> @@ -906,6 +934,9 @@ void hugetlb_cgroup_migrate(struct folio *old_folio, struct folio *new_folio)
> 	/* move the h_cg details to new cgroup */
> 	set_hugetlb_cgroup(new_folio, h_cg);
> 	set_hugetlb_cgroup_rsvd(new_folio, h_cg_rsvd);
> +
> + 	hugetlb_cgroup_move_usage(h_cg, h_cg, old_folio, new_folio);
> +
> 	list_move(&new_folio->lru, &h->hugepage_activelist);
> 	spin_unlock_irq(&hugetlb_lock);
> }
> 
> -- 
> 2.54.0
> 


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

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16  8:30 [PATCH 0/2] mm/hugetlb_cgroup: move the per-node usage along with the folio Hongfu Li
2026-09-16  8:30 ` [PATCH 1/2] mm/hugetlb_cgroup: move per-node usage on cross node migration Hongfu Li
2026-09-17  5:58   ` Muchun Song [this message]
2026-09-17  9:59     ` Hongfu Li
2026-09-16  8:30 ` [PATCH 2/2] mm/hugetlb_cgroup: move per-node usage on cgroup reparenting Hongfu Li
2026-09-17  6:08   ` Muchun Song
2026-09-17  0:53 ` [PATCH 0/2] mm/hugetlb_cgroup: move the per-node usage along with the folio Andrew Morton
2026-09-17 10:17   ` Hongfu Li

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=E35A1286-33DF-4B54-8338-888EE28BFD06@linux.dev \
    --to=muchun.song@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=almasrymina@google.com \
    --cc=colin.i.king@gmail.com \
    --cc=david@kernel.org \
    --cc=hongfu.li@linux.dev \
    --cc=kees@kernel.org \
    --cc=lihongfu@kylinos.cn \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=osalvador@suse.de \
    --cc=shakeel.butt@linux.dev \
    --cc=stable@vger.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;
as well as URLs for NNTP newsgroup(s).