On Sat, Jun 20, 2020 at 4:16 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
>
>
> Hi Deepa,
>
> Your commit 95582b008388 ("vfs: change inode times to use struct
> timespec64") changed the behaviour of some filesystems with regards to
> files from before 1970. Specifically, this line from JFS, unchanged
> since before 2.6.12:
>
> fs/jfs/jfs_imap.c:3065: ip->i_atime.tv_sec = le32_to_cpu(dip->di_atime.tv_sec);
>
> le32_to_cpu() returns a u32. Before your patch, the u32 was assigned
> to an s32, so a file with a date stamp of 1968 would show up that way.
> After your patch, the u32 is zero-extended to an s64, so a file from
> 1968 now appears to be from 2104.
>
> Obviously there aren't a lot of files around from before 1970, so it's
> not surprising that nobody's noticed yet. But I don't think this was
> an intended change.
In the case of JFS, I think the change of behavior on 32-bit kernels was
intended because it makes them do the same thing as 64-bit kernels.
I'm sure Deepa or I documented this somewhere but unfortunately it's
not clear from the commit description that actually made the transition :(.
> The fix is simple; cast the result to (int) like XFS and ext2 do.
> But someone needs to go through all the filesystems with care. And it'd
> be great if someone wrote an xfstest for handling files from 1968.
I'm sure the xfstests check was added back when XFS and ext3 decided to
stick with the behavior of 32-bit kernels in order to avoid an
inadvertent change when 64-bit kernels originally became popular.
For JFS and the others that already used an unsigned interpretation
on 64 bit kernels, the current code seems to be the least broken
of the three alternatives we had:
a) as implemented in v4.18, change 32-bit kernels to behave the
way that 64-bit kernels always have behaved, given that 99% of
our users are on 64-bit kernels by now.
b) keep 32-bit and 64-bit kernels use a different interpretation,
staying compatible with older kernels but incompatible between
machines or between running the same user space on the
same machine in either native 32-bit mode or compat mode
a 64-bit kernel
c) change the 99% of users that have a 64-bit kernel to overflowing
the timestamps in y2038 because that was what the kernel
file system driver originally implemented on 32-bit machines
that no concept of post-y2038 time.
Arnd
