On Sun, May 21, 2023 at 01:11:31AM -0700, Paul E. McKenney wrote: > On Sat, May 20, 2023 at 07:21:57PM -0700, Boqun Feng wrote: > > [Cc Paul and Mark] > > > > On Sat, May 20, 2023 at 04:06:43PM -0400, Theodore Ts'o wrote: > > > On Thu, May 18, 2023 at 07:47:35AM -0400, Jeff Layton wrote: > > > > Use the 31st bit of the ctime tv_nsec field to indicate that something > > > > has queried the inode for the i_mtime or i_ctime. When this flag is set, > > > > on the next timestamp update, the kernel can fetch a fine-grained > > > > timestamp instead of the usual coarse-grained one. > > > > > > TIL.... that atomic_long_fetch_or() and atomic_long_fetch_andnot() > > > exist. :-) > > > > > > When I went looking for documentation about why they do or this > > > particular usage pattern found in the patch, I didn't find any --- at > > > least, certainly not in the Documentation in the kernel sources. The > > > closest that I fond was this LWN article written by Neil Brown from > > > 2016: > > > > > > https://lwn.net/Articles/698315/ > > > > > > ... and this only covered the use atomic_fetch_or(); I wasn't able to > > > find anything discussing atomic_fetch_andnot(). > > > > > > It looks like Peter Zijlstra added some bare-bones documentation in > > > 2017, in commit: 706eeb3e9c6f ("Documentation/locking/atomic: Add > > > documents for new atomic_t APIs") so we do have Documentation that > > > these functions *exist*, but there is nothing explaining what they do, > > > or how they can be used (e.g., in this rather clever way to set and > > > clear a flag in the high bits of the nsec field). > > > > > > I know that it's best to report missing documentation in the form of a > > > patch, but I fear I don't have the time or the expertise to really do > > > this topic justice, so I'd just thought I'd just note this lack for > > > now, and maybe in my copious spare time I'll try to get at least > > > something that will no doubt contain errors, but might inspire some > > > folks to correct the text. (Or maybe on someone on linux-doc will > > > feel inspired and get there ahead of me. :-) > > > > > > > Paul already started the work: > > > > https://lore.kernel.org/lkml/19135936-06d7-4705-8bc8-bb31c2a478ca@paulmck-laptop/ > > Which reminds me, I need to forward-port that documentation to Mark's > latest version. ;-) Except that it appears that Mark beat me to it. ;-) Thanx, Paul
