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 033E3481AB5 for ; Wed, 8 Jul 2026 17:36:55 +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=1783532217; cv=none; b=PHuLVdMunBRGDQDTfHREDGF1XccXq6if4YDLZSrRq6Md4fHxuAzNFnOizPxXQ8jC0CEg9Q7aWT5xrMWpmwYtsi+staZwcYxjez0IawjTSLto6ltynIxnDrcvrhGHpL6+S0xt+rghGi8qqUfg81GegSq8ppFU5py4qws/8QthFFI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783532217; c=relaxed/simple; bh=LRdWlDHNNIqJiBX3EZbt6e+ORyaL/vhr+pX37uWItrQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=FHZoyOMH8jY1heTOrpcq+1BkEqpmfVv/SIzVU0ITQEChW93uite0MexK5In/U2slxO+ftKA0Cm7bdnJz+OTfzm8HNLwbRcwdf4Xhd3+Qza6RxmwKmokpwIQ7VvItlmD9hD+TnVi010aYKk/qDPZkEFK9qrQp3O2GIAp5Ybwpe5g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Gohq4OmT; 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="Gohq4OmT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19EDD1F000E9; Wed, 8 Jul 2026 17:36:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783532215; bh=5fSGtkNEGdJxANrrlZw1luedfmF/LGhVw9H890AiSnE=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=Gohq4OmT54oQiAuRoLb3+AblPONF5BBrRakh7lEgmSJpw7I2O2cLzUsk1lM78uViP r6t6AAns0U/YDRxnaXlZ3nD1aLEo8mNSLBW01efYwPVLbv9+1LdHOLEWXY5f3c2BRh YRL8BnFIk0/4ULGjgz0nRJsZm186Zx3sk0gFWLEJtOE2RdHUFGgQ7KKFtUYltyp/Zu WqLwKT/a2IGKwhB25jKKzmx34d/38fB4oIewM1/EOdumMklrLSrUYAr2RDpwRBPnGi E6jYb0IRAPMvUVfL28Bn3y3y+dbWX3Hbr6Ka+Ws7YdJs+PAGnrTdcB8lS5qctfYo/2 4mpAZ+C9oXvEQ== From: Pratyush Yadav To: Pranjal Shrivastava Cc: Pratyush Yadav , Mike Rapoport , Pasha Tatashin , Alexander Graf , Samiullah Khawaja , David Matlack , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/4] kho: Support preserving unsplit high-order pages In-Reply-To: (Pranjal Shrivastava's message of "Wed, 8 Jul 2026 17:03:01 +0000") References: <20260703020832.1731864-1-praan@google.com> <2vxz7bn5mv0n.fsf@kernel.org> Date: Wed, 08 Jul 2026 19:36:52 +0200 Message-ID: <2vxztsq9l6x7.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 Wed, Jul 08 2026, Pranjal Shrivastava wrote: > On Wed, Jul 08, 2026 at 04:11:04PM +0200, Pratyush Yadav wrote: >> On Fri, Jul 03 2026, Pranjal Shrivastava wrote: >> >> > This series is required for the ongoing effort to preserve DMA allocations >> > across KHO [1]. It addresses a fundamental mismatch between the current KHO >> > restoration logic and adds support for high-order buddy allocations. >> > >> > The Problem >> > =========== >> > The current KHO restore implementation treats all multi-page blocks as >> > split pages during restoration, i.e. kho_restore_pages() initializes >> > every 4KB page with a refcount of 1. >> > >> > However, many kernel subsystems, most notably the DMA allocator (via >> > dma_alloc_coherent), frequently return high-order non-compound pages. >> > In this unsplit state, only the head page carries a refcount of 1, >> > while all tail pages have a reference count of 0. >> > >> > Consequently, when these contiguous but unsplit blocks are restored by >> > KHO in the new kernel, the forced refcount of 1 on tail pages causes some >> > trouble with the buddy allocator. Downstream of the eventual free path >> > the __free_pages_prepare() [2] ends up calling page_expected_state() [3] >> > when is_check_pages_enabled() returns true (only when CONFIG_DEBUG_VM or >> > debug_pagealloc=on). >> > >> > This detects the non-zero refcounts on tail pages [4] and incorrectly >> > taints the kernel while leaking the pages in question. [...] >> > >> > 4. A new helper, kho_split_preserved_pages(), is provided for subsystems >> > that may need to split memory after it has already been preserved. >> >> Umm, that sounds scary... Why do you need to do that? What's the use >> case? Why is the driver reconfiguring its memory after preservation? I >> assume these are DMA buffers, so why do they suddenly look different? >> >> And in either case, why does KHO need to do the split? Why can't the >> driver unpreserve old preservation, then split the pages, and then >> preserve the new ones? > > Ack. I was trying to cover up an edge-case I guess but if we're simply > moving to an explicit restore API none on this would be needed. Even with an explicit restore API, I'd say it would be a bad idea to preserve using one API and restore using another. The driver really should be unpreserving and represerving. And even that if it really has to. -- Regards, Pratyush Yadav