On Tue, Nov 12, 2019 at 01:09:06PM +0100, Arnd Bergmann wrote: > However, as long as two observations are true, a much simpler solution > can be used: > > 1. xfsprogs is the only user space project that has a copy of this header We can't guarantee that. > 2. xfsprogs already has a replacement for all three affected ioctl commands, > based on the xfs_bulkstat structure to pass 64-bit timestamps > regardless of the architecture XFS_IOC_BULKSTAT replaces XFS_IOC_FSBULKSTAT directly, and can replace XFS_IOC_FSBULKSTAT_SINGLE indirectly, so that is easy. Most users actually use the new one now through libfrog, although I found a user of the direct ioctl in the xfs_io tool, which could easily be fixed as well. XFS_IOC_SWAPEXT does not have a direct replacement, but the timestamp is only used to verify that the file did not change vs the previous stat. So not being able to represent > 2038 times is not a real problem anyway. At some point we should probably look into a file system independent defrag ioctl anyway, at which point we can deprecate XFS_IOC_SWAPEXT. > Based on those assumptions, changing xfs_bstime to use __kernel_long_t > instead of time_t in both the kernel and in xfsprogs preserves the current > ABI for any libc definition of time_t and solves the problem of passing > 64-bit timestamps to 32-bit user space. As said above their are not entirely true, but I still think this patch is the right thing to do, if only to get the time_t out of the ABI.. Reviewed-by: Christoph Hellwig <hch@xxxxxx>
