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 1148F321445 for ; Tue, 11 Aug 2026 11:36:30 +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=1786448192; cv=none; b=foeVgEg9vVpN8Pn0WJYbd1yJSRn8Kk7qbjPu4EazBKABPmEEKJrY4d8lPGW+m5ISSKjo9Hyo1qjwWnNqY0fPcKdgzcSrMvMfwmF8fXMrm4pgPux44PY8XvsJICQPEdxUtI4+RmCwmlbiW3JniXuWkMvHHyUCeUdpnVjDSPUlzBo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786448192; c=relaxed/simple; bh=RnSovMnHdV/rWNpZuJwQcSjRnDjzWGF/+vnOka2q62o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=OyfioXwldklh2iHqkzwhwkVG9wRicthWlk+jz82YQINDPp1cJltK/ke8idGfVjA5Z2elLaEXtUOtul60S1GE8ZW56sKcIC3H6kejY8RPVp78RMCm8oM7RU+nj2DZDFeFfHXbFDlc0Ibz/CBT50gQUTTwRn0eF3ZdrHvB2AuZU+c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AepQbUvS; 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="AepQbUvS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 585481F000E9; Tue, 11 Aug 2026 11:36:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786448190; bh=3ZFxTjqYCVDel3mBfuW3KkCSTw+cakZjOBAmHaEPkPg=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=AepQbUvS3w/BT/5h4dSd/Z8AO2qZV9m2S7WE5Cck5btGEsFK21iN5IJJZvXQt+Q8y mF/hjb2oxuuLZjwGBFIgBaKkiuHNaS4fMRfcFpqanHRHudB+DzQwOk6o8R4dtVP1Za E3TDohCnhfdGNt4UoCYUxbDMxmLCsPy6lBgpMN0zHQin7i0jEm/iECq4Hl4thAX9ax TcfVD0HYwpDXWhaRJiPfB2TCh6rOIu24fOI8HSgHLLo+Yo63hG6y+wyeEHRRfzeGwA Ukrmgj0wmuTjcCGYczXnY0Ufk/Kc6s6fWmLjkfsF4Bm6j67li2fnhtkFrR4TwzD/tg xRY4fK0F/j3Lw== From: Pratyush Yadav To: Breno Leitao Cc: Mike Rapoport , 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 v5] kexec: keep the next kernel off hardware-poisoned pages In-Reply-To: (Breno Leitao's message of "Tue, 11 Aug 2026 04:17:41 -0700") References: <20260810-kexec_posioned-v5-1-95e1b5e2e656@debian.org> Date: Tue, 11 Aug 2026 13:36:25 +0200 Message-ID: <2vxzldac51om.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Tue, Aug 11 2026, Breno Leitao wrote: > On Mon, Aug 10, 2026 at 07:32:41PM +0300, Mike Rapoport wrote: >> Hi Breno, >> >> On Mon, Aug 10, 2026 at 06:32:04AM -0700, Breno Leitao wrote: [...] >> > + for (pfn = PHYS_PFN(start); pfn <= end_pfn; pfn++) { >> > + >> > + cond_resched(); >> >> cond_resched() for every pfn is too much, isn't it? > > It is what the other pfn walkers do: the kpageflags read loop in > fs/proc/page.c and read_page_owner() in mm/page_owner.c both call it > once per pfn. > > But I honestly don't have a strong opinion here, though, happy to batch > it if you prefer. Would this one look better?: > > if (!(pfn % MAX_ORDER_NR_PAGES)) > cond_resched(); > Now that we are looking at this, Sashiko also complains about a race with memory hotunplug. Can the page pointer become invalid here due to concurrent memory hotplug? The loop retrieves the struct page pointer using pfn_to_online_page() and then yields the CPU with cond_resched(). Since this iteration runs without holding get_online_mems(), could a concurrent memory hot-unplug event offline and remove the memory section while the thread is sleeping? If the vmemmap backing the struct page is freed and its page tables torn down, dereferencing the pointer in is_page_hwpoison(page) upon waking could cause a use-after-free regression. Kind of makes sense at first glance but I didn't go and look. Perhaps it is better to do the cond_resched() at the end of the loop? -- Regards, Pratyush Yadav