On 2026-06-03 14:11 +0000, Pasha Tatashin wrote: > 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.
This is safe, you are right. But I have more usability concerns from one side and the duplication it causes from the other. I can see the downside of putting the version information in the data structure itself as it either requires a different header for the first element or needlessly increases all the headers. But #define LUO_ABI_COMPATIBLE LUO_COMPAT_BASE "-" KHO_BLOCK_ABI_COMPATIBLE "-" KHO_VMALLOC_ABI_COMPATIBLE "-" KHO_RADIX_COMPATIBLE is not really digestible too. And it forces KHO users to potentially track KHO internal changes. We still don't promise any compatibility between different kernel versions so to avoid blocking this series on the decision what is the best way to convey KHO data structures compatibility I suggest to bump kho ABI version in v6.2* of the patch that adds KHO blocks and postpone this discussion to after rc1 when we'll have plenty of time. * sending a new version of a single file does same email traffic, but it confuses b4 and quite possibly other tools, so I think v7 is better. > 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. >
