From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (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 95FDE3A16BA for ; Mon, 10 Aug 2026 12:19:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786364383; cv=none; b=jsrZvOWhSHvZmUFQ62lPeene96MN1QEdIFhzCbAfrxeItoMcVzNMMc9EF+jfHPG6k1VgzoOUq9+YUT+FLyiFH/AtAZsirVZDL4ailTgYgZN3mIHbodmhJzHPcVUEPHY42WmvQ8eYl29o8JPPzVo6wHiYO0lhf2S+InOnp31Ohdk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786364383; c=relaxed/simple; bh=XLtRTKj45qsLb7dZw1QQLcqZk7hBSnk/KTeTCy94bSM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=exFF/Jl58NvwIDNblxaD8sKHbECqPLAgg3kpW7y2/uf9e5iSCLQ4edkgcOqxBrUIqDJgvmfs+4C5Kr5WyUkkMbugExEkT81dlAiNCn9lQyT42EXwL+5MLNTdfHBQLgB+m89jsDiEtjGsjfK3gkPuF2Dlem9GnVenSFyNsvxczDc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=fx3B4nGm; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="fx3B4nGm" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=c/Pw86YCt5PogCXqzDBsAcUpdrMFyTr7McP0WMQnfGo=; b=fx3B4nGmwKDfd8ozZL004I0DB0 jwjXO1/RrOicNejnDx1r+5Lfsw1fLjHdYtoNoy+S/wRxlp9iYSUyxC7HNbhtlk6XtgYs7vq5qs8WU sjR9pCpm9XM2QHYiwSgWqcZhSJI07FmFM+yx5diV3JgI/FsXwz/bsXj9B+yudBiIu2RGEaSUZ6KsP l9OiT9aHpxVQEriHfzTeuxIK+ThrtP9iqszMrOaXddkwXz72S4kWYySAygIsM4x8wcMG9BIX/VeRz mJIa69TczJNUUIGjHQg5SFYr2OZ94jXuyHj9t3cp7S37UjsspYwm19n5ACbUHvG3h/C0RsyokPe3W FdPoEUWg==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1wtOyO-002kE1-0b; Mon, 10 Aug 2026 12:19:20 +0000 Date: Mon, 10 Aug 2026 05:19:14 -0700 From: Breno Leitao To: Kiryl Shutsemau Cc: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , 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 Subject: Re: [PATCH v4] kexec: keep the next kernel off hardware-poisoned pages Message-ID: References: <20260807-kexec_posioned-v4-1-70d57f14625d@debian.org> 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: X-Debian-User: leitao On Mon, Aug 10, 2026 at 10:49:16AM +0100, Kiryl Shutsemau wrote: > On Fri, Aug 07, 2026 at 07:05:09AM -0700, Breno Leitao wrote: > > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c > > index dc770b9a6d053..e097e980b1439 100644 > > --- a/kernel/kexec_core.c > > +++ b/kernel/kexec_core.c > > @@ -212,6 +212,16 @@ int sanity_check_segment_list(struct kimage *image) > > } > > #endif > > > > + /* > > + * Reject destinations that land on hardware-poisoned memory: the > > + * relocation copy would machine-check on the bad frame. > > + */ > > + for (i = 0; i < nr_segments; i++) { > > + if (range_first_hwpoison(image->segment[i].mem, > > + image->segment[i].memsz) != PHYS_ADDR_MAX) > > + return -EADDRNOTAVAIL; > > Other -EADDRNOTAVAIL usage indicate error on user side. But this is not > a user fault. Maybe -EHWPOISON instead. Ack! > > + if (!PageHWPoison(page)) > > + /* page is good, let's go to the next one */ > > + continue; > > If you don't care about re-using clean part of poisoned hugetlb folio, > use is_page_hwpoison(page). > > This would do: > > if (!page || !is_page_hwpoison(page)) > continue; > > You would spin a bit on the same folio, but shouldn't be a big deal. right, it will spin a bit more when there is a poisoned page in the hugetlbfs folio, but it keep the code simpler, which might be a good trade-off. Let me update it and respin, --breno