[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/ ;-) Regards, Boqun > - Ted
