On Wed, Nov 13, 2019 at 5:34 PM Darrick J. Wong <darrick.wong@xxxxxxxxxx> 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@xxxxxxxxxx> 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
