On Wed, Nov 13, 2019 at 5:34 PM Darrick J. Wong darrick.wong@oracle.com wrote:
On Wed, Nov 13, 2019 at 02:42:24PM +0100, Arnd Bergmann wrote:
On Wed, Nov 13, 2019 at 6:08 AM Darrick J. Wong darrick.wong@oracle.com wrote:
On Tue, Nov 12, 2019 at 03:16:00PM +0100, Christoph Hellwig wrote:
diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c index d50135760622..87318486c96e 100644 --- a/fs/xfs/xfs_ioctl.c +++ b/fs/xfs/xfs_ioctl.c @@ -830,6 +830,23 @@ xfs_fsinumbers_fmt( return xfs_ibulk_advance(breq, sizeof(struct xfs_inogrp)); }
+/* disallow y2038-unsafe ioctls with CONFIG_COMPAT_32BIT_TIME=n */ +static bool xfs_have_compat_bstat_time32(unsigned int cmd) +{
Wouldn't we want a test here like:
if (!xfs_sb_version_hasbigtimestamps(&mp->m_sb)) return true;Since date overflow isn't a problem for existing xfs with 32-bit timestamps, right?
I'd say probably not.
This would be for a kernel that intentionally only supports y2038-safe user space to ensure that we don't get any surprises later. In that configuration, I think we're still better off not allowing broken ioctls regardless of whether the file system is also broken. ;-)
if (IS_ENABLED(CONFIG_COMPAT_32BIT_TIME))Heh, I didn't know that existed.
It barely does. At the moment it is always enabled on all architectures except for 32-bit riscv, but I submitted a patch to make it user selectable last week.
Arnd