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.
I see a similar problem in bfs, efs & qnx4. Other filesystems might also
have the same problem, but I haven't done an intensive investigation.
This started as a bit of banter, and I inadvertently noticed this bug,
so I felt I had a moral imperative to report it.
Thanks for all the work you've done on the y2038 problem; it's really
important. It might even be the right thing to do to start treating
32-bit filesystem seconds as being unsigned. But from the commit message,
that didn't seem to be the intended effect.
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.
