Details
-
Bug
-
Resolution: Fixed
-
Major
-
Lustre 2.14.0, Lustre 2.12.6
-
None
-
3
-
9223372036854775807
Description
In master the LL_IOC_MDC_GETINFO definition changed when patch https://review.whamcloud.com/36674 "LU-10934 llite: integrate statx() API with Lustre" landed:
b2_10$ git grep '#define LL_IOC_MDC_GETINFO' master:lustre/include/lustre/lustre_user.h:#define LL_IOC_MDC_GETINFO _IOWR(IOC_MDC_TYPE, 23, struct lov_user_mds_data *) master$ git grep '#define LL_IOC_MDC_GETINFO' lustre/include/uapi/linux/lustre/lustre_user.h:#define LL_IOC_MDC_GETINFO_OLD _IOWR(IOC_MDC_TYPE, 23, struct lov_user_mds_data_v1 *) lustre/include/uapi/linux/lustre/lustre_user.h:#define LL_IOC_MDC_GETINFO _IOWR(IOC_MDC_TYPE, 23, struct lov_user_mds_data)
Which is obviously bad. It's also subtly bad in that the second ioctl depends on how lov_user_mds_data is defined, and it contains a different struct statx with different field names, so while the IOC numbers/structs are ABI compatible, it is not API compatible and applications using this header will break. For added confusion, this changed in 2.12.4 vs. 2.12.3. If we add a newer structure and update the definition as we have then should definition of LL_IOC_MDC_GETINFO change as well?
The suggestion is that we do:
#define LL_IOC_MDC_GETINFO_V1 _IOWR(IOC_MDC_TYPE, 23, struct lov_user_mds_data_v1 *) #define LL_IOC_MDC_GETINFO_V2 _IOWR(IOC_MDC_TYPE, 23, struct lov_user_mds_data_v2)
in master and b2_12. Then we can use the explicitly versioned constants everywhere for the in-tree code, and declare LL_IOC_MDC_GETINFO in a compatible way, but external applications can select the version that they want explicitly.
