From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (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 33F38242D9D for ; Wed, 8 Jul 2026 17:42:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783532541; cv=none; b=PMkqVNqlgXKrGQiGnk1LyCjPiSTfxe/POgq9EKUQdwG4SLJVypvYX7tfMgyfhd/MklXXJcslOWtBTLhJkJnY8kQJuMjv2FbRN+b3N7+NoUr2RH+2MWpeE/bkN3DhYUMvFhbFGXSmr00iBQcNJ0lG4yq/0tlG90zZmjhNCbhZGYk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783532541; c=relaxed/simple; bh=8Dn7kGMKLp7TT1nb4NhZvA0LE2Yt0OnvkmbpEyfsIkw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=k4z7UFnLk/+qCBptZXvqp+fLZZWmMnmccGpGsFUdLiqGwgYj4z4ugSYF9fVq9P9mBLiuAkN0rUagSqdkE/ttOOxFmW0Bw9jsYUVLZV/ztkR1uF/DoN/Lyj66gACqnPX4DMkUJbU1VWPF6cnDzPX/vFHFfNW+DBPMHhN4Rgwq65g= 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=Mz7UYqqJ; arc=none smtp.client-ip=209.85.214.176 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="Mz7UYqqJ" Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-2cab97c86bdso7705ad.1 for ; Wed, 08 Jul 2026 10:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1783532539; x=1784137339; 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=NY8WDLERqRUUyPPjKLcGWnXs7jTmISXhATSCwU5JbWU=; b=Mz7UYqqJR75F3c35nBmZrW3pTl3Fq6KzkeS+arZJnIcwbh4DpwLNAvnF39SQz3fkIQ tY2/1aP1kGz4ztfqQ/UqLmI5du4KJbxgbmJ1JK9OOQ+tPq10I0mHndmL/nanyzH1aTY3 y8UtIUJWoLf2RHrEoPwe0FYXhn8eN3ERxreN1Af/t+kTO1+y+gHTpDYbqYZRbfCxuuy1 0JSJNYF77gWPJ/8DcMSyMOEPXYA4AFSr7I/ZLXUjYUStAyklj+0Qcf26B6oECxSyrX3F hDZeAJUyKON6k2682ucYIGM0+zxwoU0TkFT6cPncloYSRT6WhQBPlIiAQlsUtzQk2rTy eBFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783532539; x=1784137339; 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=NY8WDLERqRUUyPPjKLcGWnXs7jTmISXhATSCwU5JbWU=; b=HByWS3h28FDyvm0fSVC8n6/53C0vGwfbYk2FHa8YBX5QZ+hF9B9+q+C5NEjgFePa4c 8di6oI4CAAdbOCHLVcK8z946PrwmoMlpFETgmH/t7zf32t5v9wAoc2CaMhK5tUiF2hWa eb7rWJMbOG7ieYl5lQisN0Pv3tg+dAvCp4QN6g4Th0DC4JVp1TPG3PgNbh0BwDbAjhgr hFSj8etu1hyVfPoG27lfIjtKWJDB1ZcUr6XmT4IGerxw4S3Ox9zw/JfpZAnU32ppHYGk Z5o3V9xa+PphLFNLgiygKZNN+ehn+rHpBDTHn49lmisogPITgsIYb1P97aqxspknM/uN x8Bg== X-Forwarded-Encrypted: i=1; AHgh+RrOoxh7vUHgG0oteIDR0ZIf4WQ9IYXmypRHKsk4fC0ZXUQ5j8TJCoaMgYmCF2kkE/v58tqdubvRyUckgRc=@vger.kernel.org X-Gm-Message-State: AOJu0Yy9w8C3Vz36mscvQmr84eZdEn0Bd3rlDhxL2SHdZEvkkMbf/KWb ArfBfh3VfDlXwuMjzd/Suoed/zSCUYIhuNnusv9+74X12kYhYwIsaRx7FHUmzN6Bng== X-Gm-Gg: AfdE7cmRBHjFCD44dj7T3gldH6Xo/bCPG7NABRdO9g6JIyHtUgZMbmpCnqPwCc/5wKx Q1x7rC841k5w0pd48jxEOXZjr+FUHerlBXYa+Uo1ImZbn27vxbAlcVResjFDfOZ/fm3vhfj6IbX PaSJhachwtm9gnBQi4AmWRc2ov10ayoFk7D8WPRwYoX6tqCP+JIu7T+i+91QA/h7WjDcMMSstm0 7MYCDHvAAsjzXkJSQzExnl/vSmJPSW4U+WIoTVmOwMiCW5j7+omemU2/194acb32B9U1Arb79tI bmPN8mmC4vp/gMJ0K+NOfDgRGVEgxTuakfgfvSoqp+G/6kHeADgsfV1LGJoUh9kvgZYGFE8CDlK rwJFL6yFuy3s8E0hOrof359LB3yIDadoL0V5lisuC4x7Cm7lmVc0zpkUmdVBpNqhJgH7WHhuLtk KUtsM8gheZ9EKoCog4P7sJRNiQ1X3TNjXFRdJxTA/yJCeDVZw= X-Received: by 2002:a17:902:e806:b0:2c6:a078:bfb7 with SMTP id d9443c01a7336-2ccff8dc9a5mr327665ad.7.1783532538783; Wed, 08 Jul 2026 10:42:18 -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-847f6b609acsm7268238b3a.1.2026.07.08.10.42.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2026 10:42:18 -0700 (PDT) Date: Wed, 8 Jul 2026 17:42:12 +0000 From: Pranjal Shrivastava To: Mike Rapoport Cc: Pasha Tatashin , Pratyush Yadav , 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> <178341290876.3292146.16538284698967245356.b4-review@b4> 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: <178341290876.3292146.16538284698967245356.b4-review@b4> On Tue, Jul 07, 2026 at 11:28:28AM +0300, Mike Rapoport 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. > > This brings a broader question - what is the best way to deal with page > metadata. This particular case requires only a single bit and luckily we > have a few spare high bits in the radix tree key. But what if going > forward we'll need more than a few bits? Do we need a parallel data > structure for the page metadata? Or something in kho_radix_leaf in > addition to the bitmap? > > I'm not saying that a generic solution for page metadata must be a part > of this series, but we definitely need to consider and better sooner > than later. Ack. I agree that regarding page metadata, we are limited by the available bits in the Radix key (and as discussed with Pratysh on the other thread it increases the memory usage too). I guess we need more complex metadata in the future, a parallel data structure or expanding struct kho_radix_leaf to include a metadata array alongside the bitmap should be better in the long-ter I guess? > > > 3. kho_restore_page() applies the correct refcount pattern based on the > > preserved metadata. > > > > 4. A new helper, kho_split_preserved_pages(), is provided for subsystems > > that may need to split memory after it has already been preserved. > > > > Considerations > > ============== > > > > 1. A primary goal of this approach is to prevent driver/subsystem code > > from peeking into MM internals. Drivers should not need to understand > > the distinction between head/tail pages or compound metadata. The KHO > > core handles this internally. > > > > 2. To handle rare cases where a caller might wish to split a high-order > > block after preservation, we provide kho_split_preserved_pages(). > > Do you have anything particular in mind? Not really, I guess I was thinking of an edge case and attempted to handle it this way. We could very well write this in the kdoc that the caller who wants to do this must unpreserve first. > > -- > Sincerely yours, > Mike. > Thanks, Praan