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:
- xfsprogs is the only user space project that has a copy of this header
We can't guarantee that.
- 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@lst.de