On Tue, Jun 09 2026, Pasha Tatashin wrote: > On 06-08 21:11, Mike Rapoport wrote: >> On Mon, Jun 08, 2026 at 04:12:56PM +0000, Pasha Tatashin wrote: >> > On 06-08 13:26, Mike Rapoport wrote: >> > > On 2026-06-07 13:43:09+00:00, Pasha Tatashin wrote: >> > >> > Keeping all of that in a single KHO file is the wrong approach and goes >> > against how other logically separated subsystems in Linux are organized >> > (e.g., mm/vmap.c, mm/vmalloc.c, etc.). Yes, there are some messier >> > places in the kernel as well, but keeping this in its own dedicated >> > kho_vmalloc.c file makes complete sense to me. >> >> Either I hallucinated or b4 ate a paragraph from my reply ;) >> >> Regarding the code movement >> - splitting radix tree makes perfect sense to me, just the documentation >> part needs more care than mechanical move
+1, separating radix and KHO block makes sense. > > Agreed. I'll also pay closer attention to the documentation. > >> - I'm fine with abi/vmalloc.h, presuming KHOSER_PTR() is not part of it > > Yes, I will move KHOSER_PTR() to the shared compat.h in v2 so it's not > tied to vmalloc. > >> - I can live with kho_vmalloc.c although I still consider it unnecessary >> churn > > Appreciate it. > >> - I'm against moving vmalloc APIs from kexec_handover.h because they are >> very close in nature to folio and pages. I don't see core KHO as >> responsible for preserving physically contiguous ranges but rather as >> preserving allocations. Not sure we'll ever support kmalloc(), but still. FWIW, I agree with Mike here. I also see kho_preserve_vmalloc() as a memory preservation primitive, same as kho_preserve_folio() or kho_preserve_pages(). So I think it belongs in the main KHO header. I also think it would also be nice to have vmalloc in kexec_handover.c, but I can live with either way. > > That is a very reasonable compromise. I am fine with keeping the > consumer-facing function declarations in kexec_handover.h so they remain > grouped with folios and pages. > >> > However, overall enforcing the use of KHOSER is unrelated to this work. >> > I have my own thoughts on this, and perhaps with proper versioning, >> > using KHOSER_PTR everywhere would be appropriate, but let's keep that as >> > a separate work. >> >> This is a separate work, indeed. But regardless of the versioning it's >> already better than plain u64 because it provides type safety. It would be even nicer to have some sort of type safety for KHO vmalloc. On preservation and restore, you lose the the type of the array, and it is very easy to make mistakes. I gave it a try some time ago but unfortunately couldn't come up with anything good. -- Regards, Pratyush Yadav
