On Mon, Sep 30 2024 at 15:37, Jeff Layton wrote:

On Mon, 2024-09-30 at 21:16 +0200, Thomas Gleixner wrote:
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:

Please also add comments into the code / interface.

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.

That makes me ask a question. Are the timestamps always taken in thread
(syscall) context or can they be taken in other contexts (worker,
[soft]interrupt, etc.) too?

Thanks,

        tglx