On Wed, May 21, 2025, at 10:48, Andrey Albershteyn wrote:
> On 2025-05-19 21:37:04, Dave Chinner wrote:
>> > +struct fsx_fileattr {
>> > + __u32 fsx_xflags; /* xflags field value (get/set) */
>> > + __u32 fsx_extsize; /* extsize field value (get/set)*/
>> > + __u32 fsx_nextents; /* nextents field value (get) */
>> > + __u32 fsx_projid; /* project identifier (get/set) */
>> > + __u32 fsx_cowextsize; /* CoW extsize field value
>> > (get/set)*/
>> > +};
>> > +
>> > +#define FSXATTR_SIZE_VER0 20
>> > +#define FSXATTR_SIZE_LATEST FSXATTR_SIZE_VER0
>>
>> If all the structures overlap the same, all that is needed in the
>> code is to define the structure size that should be copied in and
>> parsed. i.e:
>>
>> case FSXATTR..._V1:
>> return ioctl_fsxattr...(args, sizeof(fsx_fileattr_v1));
>> case FSXATTR..._V2:
>> return ioctl_fsxattr...(args, sizeof(fsx_fileattr_v2));
>> case FSXATTR...:
>> return ioctl_fsxattr...(args, sizeof(fsx_fileattr));
I think user space these days, in particular glibc, expects that
you can build using new kernel headers and run on older kernels
but still get behavior that is compatible with old headers, so
redefining FS_IOC_FSGETXATTR would be considered a bug.
I'm fairly sure that in the past it was common to expect userspace
to never be built against newer headers and run on older kernels,
but the expectation seems to have gradually shifted away from that.
> So, looks like there's at least two solutions to this concern.
> Considering also that we have a bit of space in fsxattr,
> 'fsx_pad[8]', I think it's fine to stick with the current fsxattr
> for now.
You still have to document what you expect to happen with the
padding fields for both the ioctl and the syscall, as the
current behavior of ignoring the padding in the ioctl is not
what we expect for a syscall which tends to check unknown
fields for zero. I don't see a good solution here if you
use the same structure.
Arnd
