Conversation
The linux_raw backend defined the `StatVfsMountFlags` constants with the `MS_*` mount flag values, because linux-raw-sys has no `ST_*` names. `statvfs` fills `f_flag` with the kernel's `statfs` `f_flags` unconverted, and those are `ST_*` values. Most of the two sets agree, but `ST_RELATIME` is 0x1000 while `MS_RELATIME` is 1 << 21, so `f_flag.contains(StatVfsMountFlags::RELATIME)` was false on every `relatime` mount, and the bit the kernel did set was left unnamed. `f_flag` therefore could not tell a `relatime` mount from a strictatime one. A caller that derives the atime mode from these flags (neither `NOATIME` nor `RELATIME` means strictatime) and restates it in a bind remount changed every `relatime` mount it touched to strictatime, or got `EPERM` on a mount whose atime flags are locked, such as one inherited by a less privileged mount namespace. The `ST_*` values are not in the kernel's uapi headers, which linux-raw-sys is generated from, so spell them out, as the libc backend gets them from libc. Add a test that checks them against libc's on glibc, and one that compares what `statvfs` reports for `/` and `/proc` with the options in their `/proc/self/mountinfo` lines; both fail without the fix.
The libc backend defines `StatVfsMountFlags::RELATIME` only where libc has `ST_RELATIME` (Android and glibc), so the mountinfo test did not compile for x86_64-unknown-linux-musl with use-libc. Compare the other flags everywhere, and `RELATIME` where the constant exists.
hiking90
force-pushed
the
fix-statvfs-relatime
branch
from
October 3, 2026 12:28
853458a to
3628957
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On the linux_raw backend,
StatVfsMountFlagsis defined with theMS_*mount flag values, because linux-raw-sys has noST_*names.statvfsfillsf_flagwith the kernel'sstatfsf_flagsunconverted, and those areST_*values. Most of the two sets coincide, butST_RELATIMEis0x1000whileMS_RELATIMEis1 << 21. As a result,statvfs(p)?.f_flag.contains(StatVfsMountFlags::RELATIME)is false on everyrelatimemount — most mounts on a default Linux system.Reproduction: on a
relatimeroot,rustix::fs::statvfs("/")returnsStatVfsMountFlags(0x1020)(ST_RELATIME | ST_VALID), andcontains(RELATIME)is false. The libc backend useslibc::ST_RELATIMEand is correct.Impact: code that reads the per-mount flags to preserve them across a bind remount loses
relatime. In a user namespace, where atime flags are locked, the remount then fails withEPERM; outside one, it silently switches the mount to strictatime.This PR spells out the
ST_*values in the linux_raw backend, following the precedent ofEXT4_IOC_RESIZE_FS, and adds two tests: one compares the constants with libc's on glibc, and one compares whatstatvfsreports for/and/procwith their/proc/self/mountinfooptions. Both tests fail without the fix:All nine constants are written as
ST_*values, not onlyRELATIME, so that none of them depends on anMS_*value happening to be equal.Note: changing the value of a public constant is observable, but the old value of
RELATIMEnever matched anything the kernel reports in this field, so no correct caller could have depended on it.