On 06-03 16:59, Mike Rapoport wrote: > On Wed, Jun 03, 2026 at 12:05:04PM +0000, Pasha Tatashin wrote: > > On 06-03 09:49, Mike Rapoport wrote: > > > On Wed, 03 Jun 2026 03:28:58 +0000, Pasha Tatashin > > > <[email protected]> wrote: > > > > diff --git a/include/linux/kho/abi/block.h > > > > b/include/linux/kho/abi/block.h > > > > new file mode 100644 > > > > index 000000000000..8641c20b379b > > > > --- /dev/null > > > > +++ b/include/linux/kho/abi/block.h > > > > @@ -0,0 +1,56 @@ > > > > [ ... skip 25 lines ... ] > > > > +#define _LINUX_KHO_ABI_BLOCK_H > > > > + > > > > +#include <asm/page.h> > > > > +#include <linux/types.h> > > > > + > > > > +#define KHO_BLOCK_ABI_COMPATIBLE "kho-block-v1" > > > > > > It's never used by block set and after looking at the following patches I > > > found that it's appended to LUO compatible string. > > > > > > While this works for LUO, I think it should be kho_block_set_restore() > > > responsibility to verify the compatibility. > > > > It should work for any component that relies on kho_block. My proposal > > is to use this method for other common KHO data structures (e.g., kho > > vmalloc, kho radix, future kho xarray). There is no need for them to > > carry the compatibility string in their metadata, as whoever uses them > > will include their compatibility string. > > So if, say, memfd_luo uses kho vmalloc, xarray and blocks it'll have five > compatibility strings glued together?
That is correct, but it will be in only one place: the header of the client's KHO subtree. Since it is dynamically sized and 8-byte aligned, it should be safe to include in any struct. Pasha > > > For now, reviewers will have to make sure that if the ABI header content > > is changed, the compatibility string is updated. > > -- > Sincerely yours, > Mike.
