Re: [PATCH v8 01/11] timekeeping: move multigrain timestamp floor handling into timekeeper

[Jeff Layton <jlayton@kernel.org>]

On Mon, 2024-09-30 at 21:16 +0200, Thomas Gleixner wrote:
> On Mon, Sep 16 2024 at 06:57, Jeff Layton wrote:
> > On Mon, 2024-09-16 at 12:32 +0200, Thomas Gleixner wrote:
> > > > 'Something has changed' is a truly understandable technical
> > > > explanation.
> > > 
> > >      old = mg_floor
> > >                                 mono = T1;
> > >                                 mg_floor = mono
> > > preemption
> > > 
> > >      do {
> > >         mono = T2;
> > >      }
> > > 
> > >      cmpxchg fails and the function returns a value based on T1
> > > 
> > > No?
> > > 
> > > 
> > 
> > Packing for LPC, so I can't respond to all of these just now, but I
> > will later. You're correct, but either outcome is OK.
> > 
> > The requirement is that we don't hand out any values that were below
> > the floor at the time that the task entered the kernel. Since the time
> > changed while the task was already inside the kernel, either T1 or T2
> > would be valid timestamps.
> 
> That really needs to be documented. A similar scenario exists
> vs. ktime_get_coarse_real_ts64_mg().
> 

Yes.

I have the following section in the multigrain-ts.rst file that gets
added in patch 7 of this series. I'll also plan to add some extra
wording about how backward realtime clock jumps can affect ordering:

Inode Timestamp Ordering
========================

In addition to providing info about changes to individual files, file                          
timestamps also serve an important purpose in applications like "make". These                       
programs measure timestamps in order to determine whether source files might be                     
newer than cached objects.                                                                          

Userland applications like make can only determine ordering based on                                
operational boundaries. For a syscall those are the syscall entry and exit                          
points. For io_uring or nfsd operations, that's the request submission and                          
response. In the case of concurrent operations, userland can make no                                
determination about the order in which things will occur.

For instance, if a single thread modifies one file, and then another file in                        
sequence, the second file must show an equal or later mtime than the first. The                     
same is true if two threads are issuing similar operations that do not overlap                      
in time.

If however, two threads have racing syscalls that overlap in time, then there                       
is no such guarantee, and the second file may appear to have been modified                          
before, after or at the same time as the first, regardless of which one was                         
submitted first.

-- 
Jeff Layton <jlayton@kernel.org>