All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Kaitao Cheng <kaitao.cheng@linux.dev>
Cc: David Hildenbrand <david@kernel.org>, Zi Yan <ziy@nvidia.com>,
	Matthew Brost <matthew.brost@intel.com>,
	Joshua Hahn <joshua.hahnjy@gmail.com>,
	Rakie Kim <rakie.kim@sk.com>, Byungchul Park <byungchul@sk.com>,
	Gregory Price <gourry@gourry.net>,
	Ying Huang <ying.huang@linux.alibaba.com>,
	Alistair Popple <apopple@nvidia.com>,
	Naoya Horiguchi <nao.horiguchi@gmail.com>,
	Mel Gorman <mel@csn.ul.ie>, Andi Kleen <ak@linux.intel.com>,
	Muchun Song <muchun.song@linux.dev>,
	Jun'ichi Nomura <j-nomura@ce.jp.nec.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Kaitao Cheng <chengkaitao@kylinos.cn>
Subject: Re: [PATCH] migrate: Skip hwpoisoned hugetlb folios during migration
Date: Wed, 1 Jul 2026 16:05:07 -0700	[thread overview]
Message-ID: <20260701160507.7de2963010514ef7c7d99663@linux-foundation.org> (raw)
In-Reply-To: <20260701105544.97059-1-kaitao.cheng@linux.dev>

On Wed,  1 Jul 2026 18:55:44 +0800 Kaitao Cheng <kaitao.cheng@linux.dev> wrote:

> Hugetlb migration does not check whether the source folio contains
> hwpoisoned memory before trying to move it.  After the folio is unmapped,
> the move path can reach hugetlbfs_migrate_folio() and then
> migrate_huge_page_move_mapping(), which copies the source folio into the
> new folio.
> 
> That copy uses folio_mc_copy(), so architectures with recoverable
> machine-check copy support can fail the copy with -EHWPOISON.  However,
> there is no reason to attempt the move once the source folio is already
> known to contain poisoned memory.  Architectures without such copy_mc
> support also fall back to a normal copy, which can consume the poison.
> 
> Check folio_contain_hwpoisoned_page() after locking the source hugetlb
> folio and fail the migration with -EHWPOISON before unmapping or copying
> it.  This covers both a hwpoisoned hugetlb head folio and large folios
> that only have the has_hwpoisoned summary flag set.

Thanks.  I'll await reviewer input on this.

AI review suggests that a couple of other places may have the same
issue:

	https://sashiko.dev/#/patchset/20260701105544.97059-1-kaitao.cheng@linux.dev


      reply	other threads:[~2026-07-01 23:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-01 10:55 [PATCH] migrate: Skip hwpoisoned hugetlb folios during migration Kaitao Cheng
2026-07-01 23:05 ` Andrew Morton [this message]

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=20260701160507.7de2963010514ef7c7d99663@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=ak@linux.intel.com \
    --cc=apopple@nvidia.com \
    --cc=byungchul@sk.com \
    --cc=chengkaitao@kylinos.cn \
    --cc=david@kernel.org \
    --cc=gourry@gourry.net \
    --cc=j-nomura@ce.jp.nec.com \
    --cc=joshua.hahnjy@gmail.com \
    --cc=kaitao.cheng@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matthew.brost@intel.com \
    --cc=mel@csn.ul.ie \
    --cc=muchun.song@linux.dev \
    --cc=nao.horiguchi@gmail.com \
    --cc=rakie.kim@sk.com \
    --cc=ying.huang@linux.alibaba.com \
    --cc=ziy@nvidia.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.