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 1A54B4334AD for ; Wed, 12 Aug 2026 11:12:21 +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=1786533143; cv=none; b=ERh7Qp1cv1pa8A8RaPcEXjxAaoYHy8pKwr+77kw69d1A7XZwSF7lt2dRY/KGXPW/nb2+kCzVXr9QtxcM82FvHM43qHc6+v4b/V7HcEwnlhlh6/KNJ4XKvfpn+H7iuH4BeIYKLBKzBLXc7wdw9B/AaIyoWuGmmZbxuhBRkhZ2mFE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786533143; c=relaxed/simple; bh=EvrmWm8ZMOkYWKRLtMAWLqbVPMusafEiPo5+TYVKM2Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nbBCtQ78GQLObLONfXeEcht1GQlMSn8XBQaTPF3hMmbe5SEE+lvvKQDZlXFdgvCv2YrgR7ivAxxhAKsi43kY7RWzFsM5x4qTL4FeyNNMqOxtW2jRRHeHGE1cKZ0MxVwZwGB5XGSZI0UCemHEa0KCXx3qBPx10QULUsCZAxfKebs= 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=o2/oPsgT; 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="o2/oPsgT" 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=wfAKwb7BHAfKwks4BwOH8LurhNbOUrjBmbZm8v/M8ho=; b=o2/oPsgT8gcfdJPToPnecYrXEY JESoF7pDhaqGxbh9ocFyX3YVUH/FjZuDIMgtE8vfuQEIj70ltqRFqBjiIcDWdegYRMCqRYVdVuYl4 UlDTVngR5rQP97DrXqNPuQdNunlIJa7ZDeNlVB1FfnQN0PJGV8e4tpypn9hUMpwmHpR29xidDMEJU WTHogF/NFBajrCoiytFW3YQfECpHTAfXHEtxyWh/8rSTzrSR4SZwXkojbSAsw9bQ1t3J1TBRcjy5Q AoStvSzvaSIfQD2VqXmQbfl9y9x77/1080CcswJUXIj1gsFMVybP5PXZA11/KnbSgKk4nP7jAVCKo 5VEGAkAg==; 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 1wu6sK-004Ifd-32; Wed, 12 Aug 2026 11:12:01 +0000 Date: Wed, 12 Aug 2026 04:11:54 -0700 From: Breno Leitao To: Pratyush Yadav Cc: Mike Rapoport , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Baoquan He , Pasha Tatashin , 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 Message-ID: References: <20260810-kexec_posioned-v5-1-95e1b5e2e656@debian.org> <2vxzldac51om.fsf@kernel.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: <2vxzldac51om.fsf@kernel.org> X-Debian-User: leitao On Tue, Aug 11, 2026 at 01:36:25PM +0200, Pratyush Yadav wrote: > 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? Agree. I was calling cond_resched() earlier because I wanted to call it before the "continue", but it is rather unusal. Let me move it at the end of the loop. Thanks for the review, --breno