All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miaohe Lin <linmiaohe@huawei.com>
To: Breno Leitao <leitao@debian.org>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
	<kexec@lists.infradead.org>, <rmikey@meta.com>,
	<riel@surriel.com>, <kernel-team@meta.com>,
	Kiryl Shutsemau <kas@kernel.org>,
	Bradley Morgan <include@grrlz.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	"David Hildenbrand" <david@kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	"Mike Rapoport" <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	"Michal Hocko" <mhocko@suse.com>,
	Baoquan He <baoquan.he@linux.dev>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Pratyush Yadav <pratyush@kernel.org>,
	"Naoya Horiguchi" <nao.horiguchi@gmail.com>
Subject: Re: [PATCH v6 2/2] kexec: keep the next kernel off hardware-poisoned pages
Date: Tue, 18 Aug 2026 20:15:58 +0800	[thread overview]
Message-ID: <f794a7b8-ea8b-ef21-5bf7-de36f3210837@huawei.com> (raw)
In-Reply-To: <20260812-kexec_posioned-v6-2-e477887086f0@debian.org>

On 2026/8/12 19:31, Breno Leitao wrote:
> Memory failures (such as unrecoverable ECCs errors) are getting more and
> more common. The kernel knows how to handle it while running, marking it
> as poisoned (and SIGBUS user tasks).
> 
> Poisoned memory is removed from the buddy allocator, but, not from
> other places. A current problem is that kexec will load new kernel
> on top of a bad/poisoned memory, which is undesirable.
> 
> If the next kernel's image, initrd or purgatory lands on a poisoned
> frame, the relocation copy puts it on memory that is known bad. The
> error happens on the first read from a bad page, and that is what we
> want to avoid.
> 
> Skip hardware-poisoned frames that were detected by the memory failure
> subsystem earlier when placing kexec segments.
> 
> To do so, add a helper that reports the first or the last poisoned page
> in a range: memory is walked top-down by locate_mem_hole_top_down() and
> bottom-up by locate_mem_hole_bottom_up(), so each direction needs a
> different answer to stay clear of the poison.
> 
> kexec_load() gets its destinations from userspace and cannot move them,
> so there sanity_check_segment_list() just rejects a segment that happens
> to have a poisoned page.
> 
> is_page_hwpoison() also covers hugetlb, so a poisoned hugetlb folio is
> skipped as a whole.
> 
> Suggested-by: Kiryl Shutsemau <kas@kernel.org>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
> Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
> Reviewed-by: Bradley Morgan <include@grrlz.net>

Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>

Thanks.
.

  reply	other threads:[~2026-08-18 12:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 11:31 [PATCH v6 0/2] kexec: keep the next kernel off hardware-poisoned pages Breno Leitao
2026-08-12 11:31 ` [PATCH v6 1/2] kexec_file: stop the top-down search before it underflows Breno Leitao
2026-08-12 15:06   ` Bradley Morgan
2026-08-12 11:31 ` [PATCH v6 2/2] kexec: keep the next kernel off hardware-poisoned pages Breno Leitao
2026-08-18 12:15   ` Miaohe Lin [this message]
2026-08-12 11:36 ` [PATCH v6 0/2] " Bradley Morgan
2026-08-12 12:07   ` Breno Leitao
2026-08-12 12:11     ` Bradley Morgan
2026-08-19  9:36 ` Mike Rapoport
2026-08-19 10:28   ` Breno Leitao
2026-08-19 14:23   ` Bradley Morgan
2026-08-20  6:33     ` Mike Rapoport

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=f794a7b8-ea8b-ef21-5bf7-de36f3210837@huawei.com \
    --to=linmiaohe@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=baoquan.he@linux.dev \
    --cc=david@kernel.org \
    --cc=include@grrlz.net \
    --cc=kas@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=kexec@lists.infradead.org \
    --cc=leitao@debian.org \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=nao.horiguchi@gmail.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=pratyush@kernel.org \
    --cc=riel@surriel.com \
    --cc=rmikey@meta.com \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@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 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.