The struct sepol_downcall_data is badly formed for use between kernel and userspace for several reasons:
Firstly, it uses a "time_t" (now "_kernel_time_t") field, which can be variably sized, either 32-bit or 64-bit depending on the size of "long" (or now "_kernel_long_t"). This should be a fixed-size __s64 type so that it is always the same.
The change from time_t to kernel_time_t in patch https://review.whamcloud.com/37678 "
LU-13274 uapi: make lustre UAPI headers C99 compliant" may have broken ABI compatibility for 32-bit userspace (if a 32-bit l_getsepol is used in a VM), but was only landed as commit v2_13_52-157-g7a7309fa84 and b2_12_4-22-g0417dce9fc so has not been in a release yet, so can still be fixed before 2.14.0 and 2.12.5 are released.
Secondly, it has __u32 sdd_magic that is immediately before a (maybe) 64-bit field, which introduces a (maybe) 32-bit padding into the field, depending on the compiler and architecture. The 64-bit fields in a structure should always be naturally aligned on 64-bit boundaries to avoid potential incompatibility in the structure definition.
Thirdly, it has _u16 sdd_sepol_len which _may be followed by padding.
A better struct sepol_downcall_data that is safe for data transfer between the kernel and userspace would be:
We need to keep compatibility with struct sepol_downcall_data_old for some short time, because this was included in the 2.12.1 release, so lprocfs_sptlrpc_sepol_seq_write() should handle both old and new structs, with a version check for 2.16.53 or so.