Bug 1795576 - kernel: VFS and/or XFS filesystem bug with timestamp larger than 32-bit Epoch (year 2038 bug)
Summary: kernel: VFS and/or XFS filesystem bug with timestamp larger than 32-bit Epoch...
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL: https://koschei.fedoraproject.org/pac...
Depends On:
Blocks: 1795991
TreeView+ depends on / blocked
Reported: 2020-01-28 11:08 UTC by Miro Hrončok
Modified: 2021-06-09 13:11 UTC (History)
30 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Python 39460 0 None None None 2020-01-28 11:08:23 UTC

Description Miro Hrončok 2020-01-28 11:08:23 UTC
Description of problem:
Packages python3 and python39 fail to build from source in Fedora rawhide because a test apparently randomly fails on several architectures (in all cases so far at least on one).

FAIL: test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile)
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.8.1/Lib/test/test_zipfile.py", line 606, in test_add_file_after_2107
    self.assertRaises(struct.error, zipfp.write, TESTFN)
AssertionError: error not raised by write


3.8.1, 3.9.0a2, 3.9.0a3

The packages are tracked by Koschei. See:

But note that the ppc64le build is also blocked by bz1795575.

This blocks any changes to Python we need to ship. It started to happen after the update of gcc to 10.

Comment 1 Victor Stinner 2020-01-29 11:32:46 UTC
I managed to reproduce the issue on Fedora 31 on a XFS filesystem:

$ touch testfn
$ strace -o trace python3 -c 'import os; os.utime("testfn", (4386268800, 4386268800))'
$ grep ^utimensat trace
utimensat(AT_FDCWD, "testfn", [{tv_sec=4386268800, tv_nsec=0} /* 2108-12-30T01:00:00+0100 */, {tv_sec=4386268800, tv_nsec=0} /* 2108-12-30T01:00:00+0100 */], 0) = 0
$ stat testfn
Modify: 2038-01-19 04:14:07.000000000 +0100

It looks like a Linux kernel issue in the XFS filesystem: I don't think that mtime should be *silently* truncated to 2147483647.


Copy of Florian Weimer's message (https://bugs.python.org/issue39460#msg360952):

I believe you might be observing an XFS limitation in combination with a Linux VFS bug.

On disk, XFS only supports 32-bit timestamps:

typedef struct xfs_timestamp {
	__be32		t_sec;		/* timestamp seconds */
	__be32		t_nsec;		/* timestamp nanoseconds */
} xfs_timestamp_t;

This is on the roadmap being fixed.

However, the Linux VFS code does not appear to know about this. It caches the full 64-bit value. You only see the truncated value if it is read back from disk:

# touch -t 222201020304 /tmp/t
# ls -l /tmp/t
-rw-r--r--. 1 root root 0 Jan  2  2222 /tmp/t
# echo 3 > /proc/sys/vm/drop_caches 
# ls -l /tmp/t
-rw-r--r--. 1 root root 0 Oct 19  1949 /tmp/t

This is a bug in the Linux VFS layer.

Comment 2 Miro Hrončok 2020-01-29 11:43:20 UTC
Removing the high severity, we can skip this test temporarily if needed.

Comment 3 Florian Weimer 2020-01-29 11:48:39 UTC
32-bit timestamps are a missing XFS feature, requiring an on disk-format change (but perhaps without reformatting).

In the short term, the Linux VFS layer should check the limits of the underlying file system and reject nonrepresentable timestamps.

Comment 4 Victor Stinner 2020-01-29 11:50:27 UTC
I can reproduce the VFS bug on Fedora 30 with 5.2.13-200.fc30.x86_64 kernel, so it doesn't seem to be a recent regression:

$ touch testfn
$ python3 -c 'import os; os.utime("testfn", (4386268800, 4386268800))'
$ stat testfn 
Modify: 2108-12-30 01:00:00.000000000 +0100
$ sudo bash -c 'echo 3 > /proc/sys/vm/drop_caches'
$ stat testfn 
Modify: 1972-11-22 18:31:44.000000000 +0100

Comment 5 Miro Hrončok 2020-01-29 11:58:46 UTC
Some Koji buidelrs were updated:

From https://koji.fedoraproject.org/koji/taskinfo?taskID=41127107 (test passed): kernel version == 5.4.8-200.fc31.x86_64 (see root.log)
From https://koji.fedoraproject.org/koji/taskinfo?taskID=41133060 (test failed): kernel version == 5.4.12-200.fc31.x86_64 (see root.log)

Comment 6 Victor Stinner 2020-01-29 12:39:31 UTC
I tested multiple kernel versions on Fedora 31. I noticed that utime/stat behavior changed between 5.3.14-300.fc31.x86_64 and 5.4.8-200.fc31.x86_64:

* 5.3.14-300.fc31.x86_64: Modify: 2108-12-30 01:00:00.000000000 +0100 => Modify: 1972-11-22 18:31:44.000000000 +0100
* 5.4.8-200.fc31.x86_64: Modify: 2038-01-19 04:14:07.000000000 +0100 => Modify: 2038-01-19 04:14:07.000000000 +0100

I'm not sure if any of these behavior is correct :-)

Comment 7 Victor Stinner 2021-06-09 09:01:32 UTC
RHEL issue: https://bugzilla.redhat.com/show_bug.cgi?id=1795991 (sadly private)

Comment 8 Justin M. Forbes 2021-06-09 13:11:29 UTC
xfs has had support to fix this since of 5.10 kernels. As it is a new on disk format, you need to either create a new filesystem with bigtime=1 or convert an existing (unmounted) filesystem with 'xfs_admin -O bigtime=1'.  This requires a more recent xfsprogs, which exists in rawhide, but not in F34 stable.  At some point, I believe it should be the default for creating new filesystems, but it is not with the current xfsprogs.

Note You need to log in before you can comment on or make changes to this bug.