Re: [PATCH] skip testing time before epoch on mips

[Jonathan Wakely <jwakely@redhat.com>]

On 08/03/21 14:35 +0800, Chen Li wrote:
>
>When execute libstdc++ testcases on mips, I notice that last_write_time
>alawys failed, and the failed VERIFY is  "VERIFY(
>approx_equal(last_write_time(f.path), time) );" where testing time before
>than epoch.
>
>Below is the minimal case:
>
>```
>// gcc a.c
>int main()
>{
>        struct timespec times[2] = {{1, UTIME_OMIT}, {-1201, 985000000}};
>        utimensat(AT_FDCWD, "test", times, 0);
>
>}
>```
>
>$ touch test && gcc a.c && ./a.out && stat test
>  File: test
>  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
>Device: 805h/2053d      Inode: 1056841     Links: 1
>Access: (0644/-rw-r--r--)  Uid: ( 1000/  deepin)   Gid: ( 1000/  deepin)
>Access: 2021-03-08 13:52:55.966354501 +0800
>Modify: 2106-02-07 14:08:15.985000000 +0800
>Change: 2021-03-08 13:52:56.907782193 +0800
> Birth: -
>
>Undoubtedly, mtime's type is unsigned somewhere on mips.
>
>After debuging kernel, it turns out that mtime is always -1201 in
>ext4_setattr, cp_new_stat, newlstat and etc, so the problem should not
>occur in kernel space.
>
>go back to user space via copy_to_user, I finally found mips used
>"unsigned int st_mtime_sec;" in struct kernel_stat, which is used to
>receive -1201 from kernel.

I can't reproduce this on a mips64 machine:

jwakely@erpro8-fsf2:~$ uname -a
Linux erpro8-fsf2 4.1.4 #1 SMP PREEMPT Mon Aug 3 14:22:54 PDT 2015 mips64 GNU/Linux
jwakely@erpro8-fsf2:~$ apt list libc6
Listing... Done
libc6/oldstable,now 2.19-18+deb8u10 mipsel [installed]
jwakely@erpro8-fsf2:~$ touch test && ./a.out && TZ= stat test
   File: ‘test’
   Size: 0               Blocks: 0          IO Block: 131072 regular empty file
Device: 21h/33d Inode: 36596524    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1049/ jwakely)   Gid: ( 1049/ jwakely)
Access: 2021-03-08 10:52:06.855991946 +0000
Modify: 1969-12-31 23:39:59.985000000 +0000
Change: 2021-03-08 10:52:06.859992051 +0000
  Birth: -

This is an ext4 filesystem.

Do I need to compile a 64-bit executable? 

In any case, shouldn't this be fixed in glibc to return EINVAL instead
of setting a bogus time? That would make the std::filesystem library
report an error.


>Maybe sparc also suffers from this problem, but I have no machine to
>verify.

Your test case works correctly for me on sparc-linux (both 32-bit and
64-bit on ext4 and xfs filesystems):

$ uname -a
Linux gcc202 5.10.0-4-sparc64-smp #1 SMP Debian 5.10.19-1 (2021-03-02) sparc64 GNU/Linux
$ apt list libc6
Listing... Done
libc6/unstable,now 2.31-4 sparc64 [installed]
$ ./a.out
$ TZ= stat test
   File: test
   Size: 0               Blocks: 0          IO Block: 8192   regular empty file
Device: fd01h/64769d    Inode: 657291843   Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1049/ jwakely)   Gid: ( 1049/ jwakely)
Access: 2021-03-08 10:25:43.593819539 +0000
Modify: 1969-12-31 23:39:59.985000000 +0000
Change: 2021-03-08 10:34:13.711287778 +0000
  Birth: 2021-03-08 10:24:27.106598699 +0000