On Tue, Oct 1, 2024 at 3:59 AM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > Multigrain timestamps allow the kernel to use fine-grained timestamps > when an inode's attributes is being actively observed via ->getattr(). > With this support, it's possible for a file to get a fine-grained > timestamp, and another modified after it to get a coarse-grained stamp > that is earlier than the fine-grained time. If this happens then the > files can appear to have been modified in reverse order, which breaks > VFS ordering guarantees. > > To prevent this, maintain a floor value for multigrain timestamps. > Whenever a fine-grained timestamp is handed out, record it, and when > coarse-grained stamps are handed out, ensure they are not earlier than > that value. If the coarse-grained timestamp is earlier than the > fine-grained floor, return the floor value instead. > > Add a static singleton atomic64_t into timekeeper.c that we can use to > keep track of the latest fine-grained time ever handed out. This is > tracked as a monotonic ktime_t value to ensure that it isn't affected by > clock jumps. Because it is updated at different times than the rest of > the timekeeper object, the floor value is managed independently of the > timekeeper via a cmpxchg() operation, and sits on its own cacheline. > > This patch also adds two new public interfaces: > > - ktime_get_coarse_real_ts64_mg() fills a timespec64 with the later of the > coarse-grained clock and the floor time > > - ktime_get_real_ts64_mg() gets the fine-grained clock value, and tries > to swap it into the floor. A timespec64 is filled with the result. > > Since the floor is global, take care to avoid updating it unless it's > absolutely necessary. If we do the cmpxchg and find that the value has > been updated since we fetched it, then we discard the fine-grained time > that was fetched in favor of the recent update. > > Note that the VFS ordering guarantees assume that the realtime clock > does not experience a backward jump. POSIX requires that we stamp files > using realtime clock values, so if a backward clock jump occurs, then > files can appear to have been modified in reverse order. > > Tested-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx> # documentation bits > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> Acked-by: John Stultz <jstultz@xxxxxxxxxx>
