On Sat, Jun 20, 2020 at 10:59:48AM +0200, Arnd Bergmann wrote: > On Sat, Jun 20, 2020 at 4:16 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > 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. > > 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. Oh! I hadn't realised that 64-bit kernels were already using a 64-bit signed tv_sec. That makes a world of difference. > 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. Yes, I agree, knowing more of the facts, this was the right decision to make at the time, and I wouldn't change it now. Thanks!
