From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) (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 1B2791917FB for ; Fri, 3 Jul 2026 02:08:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783044517; cv=none; b=kQIVciblH4z44itn5Sq50ruUV0IKHGsTqMAp4YRfui8qzIrOR3AVvVQimzF/LM3fEGoGki9f4E3PAmvw/lRflfVGjBRZM39RFMLyd/BG8cZA5rSNXqezMVQMisE4D2yr+4vU+XOGtKTT94YahF21do66et6NnlncvM4/RzU1JWU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783044517; c=relaxed/simple; bh=nRnOQT8Vz1kJUHDocxVnpuxz0qHKLEDzLbzWbRBau+g=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=bfpudG2ZGF8zzOmC7S71gRgncRbSuD/mfrCnLImC90kunClUgOLtHx22whe6JK3zqYwQLZtmgNarFsgi13C/XWVk5EfDgj/FP02Pdwkxvf07wo9ZfE/7EQbLIDREgZFHZ0rupfN405nzaWyzKaf+v3/33/o3YcqEgAhSnvwDo0s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--praan.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=cA7doe6M; arc=none smtp.client-ip=209.85.210.202 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=flex--praan.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="cA7doe6M" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-8479b7c3adbso127245b3a.3 for ; Thu, 02 Jul 2026 19:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1783044515; x=1783649315; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=3ssAB+EsfecVy0nswhEr9TzBhCh5UgDVB8vvd9e3u/M=; b=cA7doe6MFHprBiq7+dGqME07QZhBrzwGQAoTd5PaW0AAEwjeoX7thKQzJ9rqBbwgqW 187Skuiwv7WUonVsoQwM/9aUWAjLyyq1xWRUHd+PAFqJN9qFyo79QbTNUtDROALOn2Kc 5RR3rUy+aneb1xKthzm21kMrqkkhrgWzWm3kBt1y44m9jQi9jbJuRrSw0n1dLBiYM1HP yC+2Ln6wAEpz9KhNeLocyz3ovEMzmVYVMCirrZdcjCPIshEhmaN8O8/t9sTRXPNX0mM9 CI5aBXPfPtRlHYvf2pzJBqilmtUCJj2x4GmScxdlbhizoesmHxGSC+3Gh+NkEVWqnsWW /KMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783044515; x=1783649315; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=3ssAB+EsfecVy0nswhEr9TzBhCh5UgDVB8vvd9e3u/M=; b=WY5GQwxe/bbMXd9xhXID671eCB3ngYVnSTTNrLp2cdbERGyUJLF4wuBjfY6WtIUf76 ImmD08KTYI+pfbHhh0K8+jWu9V8vyN0PfAz1CPFQYeMN+dKP3cik1CPrUm+oulEsxVXP JIOXfxN36erBlqfjG3pQ9vLpJ0dvnGXMVTvTkkq0YkJ9/wJCRSlh0zeHdVsKU8zMRlqi izgXW7yat5pIJFwOGEmiy81QIouYBLEURR+QVLX7dWV9DY9lvDOil8ifn2YQgaS2sl1j YwUtOAJ8QN70nPyVpb0soTPKheOwowdj8sRG3aTMhBLhylSZXNhmaRBw5lgRRyZ2nLrm MOKw== X-Forwarded-Encrypted: i=1; AHgh+RqHGnzcosclKfL67Rvtty3lZTKxpiQ4lQK4MjXZ6zDB2vd+slDQkJ/OKZ1ngYPv/sD8xk7GxnOHYhZhrK4=@vger.kernel.org X-Gm-Message-State: AOJu0YyCtg2FpFhWk2P7m6db6t1ElOp2D3TqEs99SL0Pd54dGsmRmr31 ezEUxd5TQcvfQ3RvZo7ah73wrhmb3IQKKJrSU6GIW+XMtqIaoKdQWfwbeaV2i5vG+EKxMb3bdJA U/g== X-Received: from pfblg25.prod.google.com ([2002:a05:6a00:7099:b0:847:80c0:ec04]) (user=praan job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3e08:b0:845:48be:b046 with SMTP id d2e1a72fcca58-847c0854fcdmr8315059b3a.36.1783044514968; Thu, 02 Jul 2026 19:08:34 -0700 (PDT) Date: Fri, 3 Jul 2026 02:08:28 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.55.0.rc0.799.gd6f94ed593-goog Message-ID: <20260703020832.1731864-1-praan@google.com> Subject: [RFC PATCH 0/4] kho: Support preserving unsplit high-order pages From: Pranjal Shrivastava To: Mike Rapoport , Pasha Tatashin , Pratyush Yadav Cc: Alexander Graf , Samiullah Khawaja , David Matlack , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Pranjal Shrivastava Content-Type: text/plain; charset="UTF-8" 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. 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(). 3. The callers must ensure that the split_page() doesn't race with kho_preserve_pages for consistency. 4. Folios are always implicitly considered of the CONTIG type Thanks, Praan [1] https://lore.kernel.org/all/20260505002737.2213734-1-skhawaja@google.com/ [2] https://elixir.bootlin.com/linux/v7.1.1/source/mm/page_alloc.c#L1370 [3] https://elixir.bootlin.com/linux/v7.1.1/source/mm/page_alloc.c#L1027 [4] https://elixir.bootlin.com/linux/v7.1.1/source/mm/page_alloc.c#L1034 Pranjal Shrivastava (4): kho: Introduce infrastructure to track preserved page types kho: Detect preserved page types kho: Implement page-aware refcount restoration kho: Introduce kho_split_preserved_pages() helper include/linux/kexec_handover.h | 7 ++ include/linux/kho_radix_tree.h | 17 +++- kernel/liveupdate/kexec_handover.c | 144 +++++++++++++++++++++-------- 3 files changed, 124 insertions(+), 44 deletions(-) base-commit: 87320be9f0d24fce67631b7eef919f0b79c3e45c -- 2.55.0.rc0.799.gd6f94ed593-goog