From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6C85E1FE47B for ; Fri, 5 Jun 2026 22:06:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780697182; cv=none; b=an52LndbRaZcK3QsSfl4ZQWxxIeFPnZtpBsHCdGVW5FfM8Lq1iXMUMFkDCJrxOdF32AhoKuiWe6h5Ja76I8ZQ+mjRl1aDczwtLIVcAXem3RzJ7/HG5Lx1X/Ap1IcQEHbX+QiIHCLMr9bRnXciPFaIUrM62hruwShUvfCiqRYwdI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780697182; c=relaxed/simple; bh=zj3vX/bJoVfjojRJ4PSExdQ6Sp3jcCEV8Ji6IqdxrPE=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=hQJgUFXd+0gsC477p0+y5Jz8dyRsDhTfmAIh8F8u45EI2cVLiIJYmzXwpwli/2vz2foGcQcIZhFuL/yxg36IDnxIw7vUaSiT24neh3Lg+PMVgR13aCB4rClH8y3UyzZz5BNl513N38cehEMmtrASvJv/lmjiH3mXWBnmB1axXOM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=PLn4vmsu; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="PLn4vmsu" Received: by linux.microsoft.com (Postfix, from userid 1241) id B2A7C20B716A; Fri, 5 Jun 2026 15:06:05 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com B2A7C20B716A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1780697165; bh=+dlFga+Oz0ksDU1MPUq6Cr6bGtopVR7dn8Q0PHzd5jE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=PLn4vmsu0/on3FCK4E1uJjydGEvJ31dEBCE4GBE1Xe6tfbCFog9VpNfz/Jzxs6X0S IGtxK99fv5m+xh5JDAk9kx6SXi/V/w0BdxeA2K7AKomswNR6c/mQFyhRe5niMkW7NJ gtLcZ+JR1R9RpKTnwafLEM0cI9bYG/82pkb49aaE= Received: from localhost (localhost [127.0.0.1]) by linux.microsoft.com (Postfix) with ESMTP id B07C13070552; Fri, 5 Jun 2026 15:06:05 -0700 (PDT) Date: Fri, 5 Jun 2026 15:06:05 -0700 (PDT) From: Jork Loeser To: Pratyush Yadav cc: Mike Rapoport , Pasha Tatashin , Alexander Graf , Muchun Song , Oscar Salvador , David Hildenbrand , Andrew Morton , Jason Miu , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 02/18] kho: disallow wide keys in radix tree In-Reply-To: <20260605183501.3884950-3-pratyush@kernel.org> Message-ID: References: <20260605183501.3884950-1-pratyush@kernel.org> <20260605183501.3884950-3-pratyush@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; format=flowed On Fri, 5 Jun 2026, Pratyush Yadav wrote: > From: "Pratyush Yadav (Google)" > > The KHO radix tree was designed to track preserved pages. So it does not > provide the capability to track any 64-bit key. Instead, it limits the > key width to how much it needs for tracking PFNs and their orders. > Limiting the width reduces the number of levels in the tree. > > KHO is not expected to be the only user of the radix tree. With the API > generalized to allow other users, now it is possible to add any key to > the tree. > > Check the key width at kho_radix_add_key(), and error out if it exceeds > what the tree can handle. Do this instead of increasing the tree depth > since right now there are no users that need to use wider keys, so this > avoids memory overhead and ABI breakage. > > Signed-off-by: Pratyush Yadav (Google) > --- > include/linux/kho/abi/kexec_handover.h | 8 ++++++++ > kernel/liveupdate/kexec_handover.c | 12 ++++++++++++ > 2 files changed, 20 insertions(+) > > diff --git a/include/linux/kho/abi/kexec_handover.h b/include/linux/kho/abi/kexec_handover.h > index fb2d37417ad9..6dbb98bfb586 100644 > --- a/include/linux/kho/abi/kexec_handover.h > +++ b/include/linux/kho/abi/kexec_handover.h > @@ -278,6 +278,14 @@ enum kho_radix_consts { > KHO_TABLE_SIZE_LOG2) + 1, > }; > > +/* > + * The maximum key width this radix tree can track. > + * > + * This value isn't ABI itself, but it is derived from values that are ABI. > + */ > +#define KHO_RADIX_KEY_WIDTH (((KHO_TREE_MAX_DEPTH - 1) * KHO_TABLE_SIZE_LOG2) + \ > + KHO_BITMAP_SIZE_LOG2) Love the auto-derivation of these values, this totally makes sense. That said, my lazy brain complained a bit when I asked it "so how many bits can a consumer actually use?". So I wonder: 1) Why is the value not "ABI itself"; it feels like it should as it determines client behavior. 2) Would you consider expanding the actual values for the most relevant architectures (x86-64 w/ 4kb pages, arm64 w/ 4k/16/64k page-sizes) and put it in a block-comment? > + * NOTE: Currently only keys of width up to %KHO_RADIX_KEY_WIDTH are supported. > + * This limit only exists because current users of the radix tree don't use more > + * than that. Changing the maximum width requires changing the tree depth, which > + * needs bumping the ABI version. It takes longer to walk the tree. The current implementation is a good tradeoff. Best, Jork