From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AC529239085 for ; Wed, 1 Jul 2026 23:05:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782947109; cv=none; b=ktu55qe4fHlCv6tNkohr6rq/3zqq2oP8D7dShKapsFC8AIEg4v2OPh5Hjl0bOpfWIHa2B4p1SlYGPRWuUY6IkZnOvUuK2ukt5s+33gzbwy4PaazT2Hqlu1zxAoJRL8pesWWVDV4IZRECYKtucmLajyVUsnNRsqA5uX23I+5UZzY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782947109; c=relaxed/simple; bh=NyWfxcpsK5ZtS3kj1MfdwQLb5xoF+l00T0U6nFe5R70=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=ageLRclRXv3QOeSLgKyW5cgplDhFJoH731iEULGLeUU5CiM4jB4XfrKfJ2/DBs9uGF3E6w37L2enNTLxr5vIstjy8XKq5La4lc9RfYEgRulbR7hrQcD+MhHN7a34Hg9swsiX2BP6vNdZbzMWT990sPJQ+hDpQCmCBWDQJrdXscE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=gkcATlG7; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="gkcATlG7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F9111F000E9; Wed, 1 Jul 2026 23:05:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1782947108; bh=v/JfeVqatnB0TCG4L6jVrxJqSNbm5qhc0oOHBnDokaU=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=gkcATlG7LPoo0hXTbyqXHxs47MdITsNKA3hq+cmjwnEmp8e9MdiOIkmykjiu2qchy tYHXWXVtL8mU+hfGHi4OA5mEhgguTKaacR2gRq7xA4xi8/erQwA+OvtQk6M+limcwl iWHVPAa0qpjMa49Q53lP2RcrbX2t7UR5bp2DnhMQ= Date: Wed, 1 Jul 2026 16:05:07 -0700 From: Andrew Morton To: Kaitao Cheng Cc: David Hildenbrand , Zi Yan , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Naoya Horiguchi , Mel Gorman , Andi Kleen , Muchun Song , Jun'ichi Nomura , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Kaitao Cheng Subject: Re: [PATCH] migrate: Skip hwpoisoned hugetlb folios during migration Message-Id: <20260701160507.7de2963010514ef7c7d99663@linux-foundation.org> In-Reply-To: <20260701105544.97059-1-kaitao.cheng@linux.dev> References: <20260701105544.97059-1-kaitao.cheng@linux.dev> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 1 Jul 2026 18:55:44 +0800 Kaitao Cheng 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