From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 07FEA3B813A for ; Wed, 8 Jul 2026 17:03:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783530192; cv=none; b=Ru1sdxahgdCC/PYINrOJuY1hrHAl9iHSqCCFLLwkSosWAbc5hwcqzaacshPLXEMjL96hPABz52U3kTs2Fjvadl1QrT6Km82j1x0s+km6t6hnBZkYJZDLDMfU4Ynabr2wFRl8phorcuuLJHQyfuRuyFk/t1mUGXF/D/gKJbGIETQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783530192; c=relaxed/simple; bh=uKwLM121sS7uZuMRd4GI+qwLpce/F428R+S6nmbM000=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=q5XDszFPxNPwBNqGcCUf8SKZH1jAq61jxJRbyTuSSOr0dcGYn+h503rMrIOAQn+XgSBdl+5uT0lGxSVf7z/dBpbhCBOUibtfraNekEdJHjW9Ner6c24gB1TlPNXKtzpKYgvGOQNOKIwYPOscYUNTLPyosT/cI0VO9W7E9SzCw1c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=rVuNd+Y4; arc=none smtp.client-ip=209.85.214.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="rVuNd+Y4" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2cb59f6ba26so2865ad.0 for ; Wed, 08 Jul 2026 10:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1783530188; x=1784134988; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=0rcxz3xIlmj9F6FAJyNtBM4J//L5BtHyiG09PcS+rH0=; b=rVuNd+Y4RmOWGCAjRioTQ6TKjg0gDwTZitPt44iygJY/hhbUauBkgS03puzEOIZovN 3T6tI4pXQn1TSxI3M8eEVw2VzsBe4zsEK6hRN7lETjY3oHASpuA/LFuNR98RTbkkuL2m jzoLJ/qObzDYdLcqHwlIKEJ+xmphicoFqo0SqsK2eU6GMt6kS79itTKLbdNTlcQn5xcV f8j2Un0Eaox2jYFnCdm7qNIXA2AjQlrinEF5hRm/ppnY5J21Z/IVX7d6GbmN66FPMufj Rgu9wp3y5Vz2Y6/CizTPwQtgKjT1R+CuvVv0xTAN1l6GOl2IkjC+W5RqG7x9UcofOBHm Fr7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783530188; x=1784134988; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=0rcxz3xIlmj9F6FAJyNtBM4J//L5BtHyiG09PcS+rH0=; b=VApVDvk7/vVAwVTSufL9h22OQM+oKx1UfkZGsTrxbIfn67DgAaUKn/dvAJYGd6YSYL FT8W5fYZUCxCsuxl95WuddzFtHWmOTuGvVNFJ3q0P6SDhhGOES8Cz+Cv+9HnBB3mJswz pYxtVm8PcjaFAie33RFDr9PqgJiWpK98QRoV4lYKQW/yYcEVabrU/N+WmDGQXJ+AsEWL k0zaXdyPNkVttX6hQScJNc6U2VLa0TiXstP3yH6I6XKXKOvhO2wE7RMGpkibU9qWbts0 5bsyqTC/hU1p6+wtmxPrN05g6Ws4tK/P2TMieuXKV0u/CppoBH4UYCR/Qb6TgsH1iEY3 WPrQ== X-Forwarded-Encrypted: i=1; AHgh+RpufahG7E2Hb7V8cBpi5LSI44W24YomuVgQy9ykZJ9pFwDEMIwL4UEKjkmSBhTtf+FK8Mddft3FwzCcd5o=@vger.kernel.org X-Gm-Message-State: AOJu0YxX6f430wH+qf6SOOnd29HBF59IA+x0/nlzQwWtgou4pm0y7Wv4 3/GzdOBe1+VUvt280FR/OUalKwqOgJt3+mS3hi541YPLSy9KAUGHywtZ/7mP64bfhwtRRnHS/T2 gc61AYg== X-Gm-Gg: AfdE7cmLHW1ka7VOcpTIDVXyPBD7Yxbxf+1onvXgA1rOyz53Vx2+pXgE+zrYGQfk78D G+p9ODxYf79MGFxbiP/DyFj+949n//3ZH06SrJK3gy4rPtJ/2/n/IOsnyzYOkVnNMHtt0C6jDCT T83xcfNqZ/tnz5ROggPr/06jQHHlgi1vSsXxrgyXpPa/gTk+Ruv57dpYMNztGwSmuRUoEvMEr/r 67hyQzQJhhJ5lo5nww95OxGo+ST4Ko3psTinf4IoBLao9YmqifNSt2OP5l0GkrWZhKVT3KgRt13 6g1vOPDyIdv16X4KqJvW93vv8gUz4gaaMffCOHBPYdq+6M9wGHxXhxH/pSDnxLFYer6X1WYd6fl qI+63vb+dIYp2rf5IpYWF1A1UCvGTd+MxT/2glwBQswZoH2PQy3hahUY1O+hXs8GbqY8caxN160 Hikj0wcQbw3MfnHUIbJd9iiRbGNdlwDrs199B08OEuEtC7NUo= X-Received: by 2002:a17:902:e752:b0:2bd:6dad:3dfb with SMTP id d9443c01a7336-2ccff969666mr193175ad.25.1783530187903; Wed, 08 Jul 2026 10:03:07 -0700 (PDT) Received: from google.com (10.129.124.34.bc.googleusercontent.com. [34.124.129.10]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-847f6b64819sm7622445b3a.12.2026.07.08.10.03.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2026 10:03:07 -0700 (PDT) Date: Wed, 8 Jul 2026 17:03:01 +0000 From: Pranjal Shrivastava To: Pratyush Yadav Cc: 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 Message-ID: References: <20260703020832.1731864-1-praan@google.com> <2vxz7bn5mv0n.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: <2vxz7bn5mv0n.fsf@kernel.org> 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. > > > > Proposed Solution > > ================= > > This series introduces a "Page Type" field to the KHO ABI to track the > > refcount pattern of the preserved pages. > > > > 1. KHO detects the physical state (CONTIG vs SPLIT) during preservation > > by peeking at the refcount of the second page in each buddy block. > > > > 2. The type bit is preserved in the high bits of the KHO radix tree key > > (Bit 63) and stashed in page->private metadata during boot. > > The KHO radix tree today only guarantees support for 53 bit wide keys. > Although in practice, on 4k pages the math works out to support 60 bit > wide keys in practice because we have 6 table levels. > > Still, you can't preserve a key with the 63rd bit set. So how does your > code even work? > > Also, if you do this, it comes with a side effect. It will increase the > memory usage of the radix tree, since now you have two branches of the > tree, one with the high bit set, and one without it. So that is more > intermediate table pages allocated. I agree that this would increase the memory usage... > > > > > 3. kho_restore_page() applies the correct refcount pattern based on the > > preserved metadata. > > Why do you need to save the type of pages in KHO metadata? For example, > for pages or folios, we don't store any type information and leave it to > the caller choose the right API. So reserve-mem and kho vmalloc need > pages, they can call kho_{preserve,restore}_pages(), and memfd needs > folios so it can call kho_{preserve,restore}_folio(). The radix tree > itself does not hold the information. The caller knows what its memory > is supposed to be so it calls the right restore API. > > So why can't we add a kho_{preserve,restore}_page_multi() (pick a better > name; we can argue about the naming later)? Then your driver knows it is > restoring DMA buffers so it can call kho_restore_page_multi(), and KHO > takes care of initializing the pages with the right refcounts. > > You won't have to muck about with the ABI in that case. > Ack. My goal was to keep the KHO API opaque to prevent every driver from having to peak into MM refcount internals. However, if the preference is for explicit intent, I can simply introduce something like a kho_restore_pages_unsplit() helper (or similar) that drivers can call specifically for high-order non-compound DMA buffers. > > > > 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. Thanks, Praan