linux-kernel - Re: [PATCH v4 1/2] kho: Adopt radix tree for preserved memory tracking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aWYt0gBHxDCKqj9Q@kernel.org>
Date: Tue, 13 Jan 2026 13:34:42 +0200
From: Mike Rapoport <rppt@...nel.org>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Jason Miu <jasonmiu@...gle.com>, Alexander Graf <graf@...zon.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Baoquan He <bhe@...hat.com>, Changyuan Lyu <changyuanl@...gle.com>,
	David Matlack <dmatlack@...gle.com>,
	David Rientjes <rientjes@...gle.com>,
	Pasha Tatashin <pasha.tatashin@...een.com>,
	Pratyush Yadav <pratyush@...nel.org>, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v4 1/2] kho: Adopt radix tree for preserved memory
 tracking

On Mon, Jan 12, 2026 at 10:39:04AM -0400, Jason Gunthorpe wrote:
> On Mon, Jan 12, 2026 at 12:15:54PM +0200, Mike Rapoport wrote:
> > > + * The tree is traversed using a key that encodes the page's physical address
> > > + * (pa) and its order into a single unsigned long value. The encoded key value
> > > + * is composed of two parts: the 'order bit' in the upper part and the 'page
> > > + * offset' in the lower part.::
> > > + *
> > > + *   +------------+-----------------------------+--------------------------+
> > > + *   | Page Order | Order Bit                   | Page Offset              |
> > > + *   +------------+-----------------------------+--------------------------+
> > > + *   | 0          | ...000100 ... (at bit 52)   | pa >> (PAGE_SHIFT + 0)   |
> > > + *   | 1          | ...000010 ... (at bit 51)   | pa >> (PAGE_SHIFT + 1)   |
> > > + *   | 2          | ...000001 ... (at bit 50)   | pa >> (PAGE_SHIFT + 2)   |
> > > + *   | ...        | ...                         | ...                      |
> > > + *   +------------+-----------------------------+--------------------------+
> > > + *
> > > + * Page Offset:
> > 
> > To me "page offset" reads as offset from somewhere and here it's rather pfn
> > on steroids :) 
> > Also in many places in the kernel "page offset" refers to the offset inside a
> > page.
> > 
> > Can't say I can think of a better name, but it feels that it should express
> > that this is an address more explicitly.
> 
> It is "Shifted Physical Address"
> 
> > > +			node = phys_to_virt((phys_addr_t)node->table[idx]);
> > > +	}
> > > +
> > > +	/* Handle the leaf level bitmap (level 0) */
> > > +	leaf = (struct kho_radix_leaf *)node;
> > > +	idx = kho_radix_get_index(key, 0);
> > > +	__clear_bit(idx, leaf->bitmap);
> > 
> > I think I already mentioned it in earlier reviews, but I don't remember any
> > response.
> > 
> > How do we approach freeing empty bitmaps and intermediate nodes?
> > If we do a few preserve/uppreserve cycles for memory that can be allocated
> > and freed in between we might get many unused bitmaps.
> 
> Surely this is an error case??
> 
> We shouldn't be unpreserving at all in a normal flow?

That's an error case for KHO/LUO, but might not be an error case for other
users of the kho_radix_tree.
For example mshv intends to use kho_radix_tree to track the hypervisor
memory and there unpreserving will be a part of the normal flow.

I'm not saying we must implement freeing of empty bitmaps from day 1, but
at least there should be a comment about it.
 
> Jason

-- 
Sincerely yours,
Mike.