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 E566B19F115 for ; Thu, 20 Aug 2026 06:34: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=1787207650; cv=none; b=sS0wO5nJk2WpaPOfi8dAS0/pJGissnzXCn8dx6yaJ73PlXoK9Dbdnw6VO49G1G4vQKztna/psIa++my4LXJaHB5GUIIwSWB2NxoJoBSA5HCE7aeKRsK8aCo+XCoMXq9h9nMkDoEozTVag1kPmyqMm7KuKXrQVor+MlM9/pjbW+Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787207650; c=relaxed/simple; bh=UlI1vylZVj15gGGmtj50BIxXJME53tMcHDGDCg6lcJs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RvtFJoe+2em4zd4c7yu1KCBQcaYIfbFShq+FFP+jYfw/Y2T3HQU672iK3Jqro7VLM/CGnf49E4eODiVSQ955JcRGI4jbnQb3hYt94gQgZ11Fok5RPUW1kS4K8GLDJknacGLHeO/QV1OY2SCrTCLMi3QI7EmJTkzfctDBiIumaEg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ebF9ekYr; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ebF9ekYr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA9B91F000E9; Thu, 20 Aug 2026 06:34:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787207648; bh=PENPtk/etW4kWB3HZkvkr6lSKI29AakIAu1GkDMjdFw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ebF9ekYrq4pFO8UvvsUouw/6fE9Fsy6YYnnQgly9lXag3wmXe2O2LUKWPnid2d5u5 xoUCUiE0Nrpo3JreFr3Syjku1a7cUxzCBA51BXeomQ8LaCQn+C6YG4kpXSJt1GtsAH My/UFQ2eW1ZQU3qsffJf6WIgR/Khn9xodUEjafPD2GIEsZzPkmlff44gxuMYI4sJdz EBc4Vh9flLcx883zbmN0bcOeM7fkuA/1D6Ti40wSJyCks9BsMs9YE7veLfrBS6/rxc 2v2cYXv/TNHMJjk/y8tFDRk2M9pL1iAvbhsC3frEwJPHH1EBl0kaSqlmjIqbfAeyGz or5FSHtZaE6PQ== Date: Thu, 20 Aug 2026 09:33:58 +0300 From: Mike Rapoport To: Bradley Morgan Cc: Breno Leitao , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Baoquan He , Pasha Tatashin , Pratyush Yadav , Miaohe Lin , Naoya Horiguchi , 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 Subject: Re: [PATCH v6 0/2] kexec: keep the next kernel off hardware-poisoned pages Message-ID: References: <20260812-kexec_posioned-v6-0-e477887086f0@debian.org> <6CB4696E-03E3-42A0-9E3B-6BD1E143D5ED@grrlz.net> 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-Disposition: inline In-Reply-To: <6CB4696E-03E3-42A0-9E3B-6BD1E143D5ED@grrlz.net> On Wed, Aug 19, 2026 at 03:23:04PM +0100, Bradley Morgan wrote: > On 19 August 2026 10:36:17 BST, Mike Rapoport wrote: > >On Wed, Aug 12, 2026 at 04:31:50AM -0700, Breno Leitao wrote: > >> Memory failures are common enough on large fleets that kexec regularly > >> lands the next kernel on a frame the memory failure subsystem has > >already > >> marked bad. Patch 2 teaches the segment placement to avoid those frames. > >> > >> Patch 1 is a prerequisite. locate_mem_hole_top_down() walks candidates > >> downwards without ever checking that the subtraction stays above zero, > >so > >> the walk can wrap and report success with a destination outside of RAM. > >> Patch 2 adds one more downward step to that loop, so the bug is fixed > >> first and both patches rely on the same bail-out. > > > >I queued this for v7.4, the patches will appear in the liveupdate tree > >after the merge window. > > > > Ah, so it'll appear in a maintainers tree after MW? Yes > >> Signed-off-by: Breno Leitao > >> --- > >> Changes in v6: > >> - Split the pre-existing top-down underflow out into its own patch, and > >> drop the "if (poison < kbuf->memsz)" guard from the hwpoison hunk now > >> that the loop bail-out covers it. (Mike Rapoport, Sashiko) > >> - Reword the changelog: the MCE comes from reading the poison back, not > >> from the relocation copy writing it, and the placement paragraphs read > >> better split up. (Mike Rapoport) > >> - Move cond_resched() after the struct page dereference, so the scan > >does > >> not yield between pfn_to_online_page() and is_page_hwpoison(). > >> (Pratyush Yadav, Sashiko) > >> - Keep cond_resched() per pfn rather than batching it. (Kiryl Shutsemau, > >> Rik van Riel) > >> - Link to v5: > >https://patch.msgid.link/20260810-kexec_posioned-v5-1-95e1b5e2e656@debian.org > >> > >> Changes in v5: > >> - Return -EHWPOISON instead of -EADDRNOTAVAIL > >> - Leverage is_page_hwpoison() instead of per-page check > >> - Link to v4: > >https://patch.msgid.link/20260807-kexec_posioned-v4-1-70d57f14625d@debian.org > >> > >> Changes in v4: > >> - Anchor the top-down hole finder on the first poisoned page in the > >> window and the bottom-up one on the last, so each jumps clear of the > >> poison in one step. New range_first_hwpoison(). (Kiryl Shutsemau) > >> - Count a poisoned hugetlb folio in full: the flag lives on the folio, > >> not on the subpages, so the per-pfn scan missed poisoned tail pages. > >> (Kiryl Shutsemau) > >> - Link to v3: > >https://patch.msgid.link/20260803-kexec_posioned-v3-1-83aa6ede0351@debian.org > >> > >> Changes in v3: > >> - Return the address of the last poisoned page in the range, or > >> PHYS_ADDR_MAX when it is clean, instead of a bool plus an output > >> parameter. Renamed to range_last_hwpoison(). (Pratyush Yadav) > >> - Add cond_resched() to the scan loop, as a segment can span half of > >> memory. (Sashiko) > >> - Link to v2: > >https://patch.msgid.link/20260730-kexec_posioned-v2-1-f92d18551f64@debian.org > >> > >> Changes in v2: > >> - Change from pfn_to_page() to pfn_to_online_page(). (Miaohe Lin) > >> - Return the poisoned address once we find a hit, to avoid the O(n^2) > >> rescan. (Sashiko) > >> - Link to v1: > >https://patch.msgid.link/20260728-kexec_posioned-v1-1-160c81d180fe@debian.org > >> > >> To: Andrew Morton > >> To: David Hildenbrand > >> To: Lorenzo Stoakes > >> To: "Liam R. Howlett" > >> To: Vlastimil Babka > >> To: Mike Rapoport > >> To: Suren Baghdasaryan > >> To: Michal Hocko > >> To: Baoquan He > >> To: Pasha Tatashin > >> To: Pratyush Yadav > >> To: Miaohe Lin > >> To: Naoya Horiguchi > >> Cc: linux-mm@kvack.org > >> Cc: linux-kernel@vger.kernel.org > >> Cc: kexec@lists.infradead.org > >> Cc: rmikey@meta.com > >> Cc: riel@surriel.com > >> > >> --- > >> Breno Leitao (2): > >> kexec_file: stop the top-down search before it underflows > >> kexec: keep the next kernel off hardware-poisoned pages > >> > >> include/linux/mm.h | 14 ++++++++++++++ > >> kernel/kexec_core.c | 10 ++++++++++ > >> kernel/kexec_file.c | 20 +++++++++++++++++++- > >> mm/memory-failure.c | 40 ++++++++++++++++++++++++++++++++++++++++ > >> 4 files changed, 83 insertions(+), 1 deletion(-) > >> --- > >> base-commit: c5e32e86ca02b003f86e095d379b38148999293d > >> change-id: 20260727-kexec_posioned-72bb0a4143a0 > >> > >> Best regards, > >> -- > >> Breno Leitao > >> > > > > > > Thanks! -- Sincerely yours, Mike.