[LTP] [PATCH] block: fix FS_IOC_GETLBMD_CAP parsing in blkdev_common_ioctl()

[Arnd Bergmann]

On Thu, Jul 10, 2025, at 12:59, Christoph Hellwig wrote:
>> I think the variant from commit 1b6d968de22b ("xfs: bump
>> XFS_IOC_FSGEOMETRY to v5 structures") where the old structure
>> gets renamed and the existing macro refers to a different
>> command code is more problematic. We used to always require
>> userspace to be built against the oldest kernel headers it could run
>> on. This worked fine in the past but it appears that userspace
>> (in particular glibc) has increasingly expected to also work
>> on older kernels when building against new headers.
>
> This is what I meant.  Note that the userspace in this case also keeps a
> case trying the old structure, but that does indeed require keeping the
> userspace somewhat in lockstep if you do the renaming as in this example.

Right, it's fine for applications that keep a copy of the uapi
header file, because they can implement both versions when they
update to the new version of that file.

Redefining the ioctl command code does break if you have an
unmodified application source tree that unintentionally uses
the updated /usr/include/linux/*.h file. In this case there is
no benefit from the new header because it isn't aware of the
new struct member but it still ends up failing on old kernels.

   Arnd