lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 1 Nov 2023 12:23:44 -1000
From:   Linus Torvalds <>
To:     Trond Myklebust <>
Cc:     Jan Kara <>, Chris Mason <>,
        Josef Bacik <>,
        John Stultz <>,
        "Darrick J. Wong" <>,
        Christian Brauner <>,
        Chandan Babu R <>,
        Hugh Dickins <>,
        linux-xfs <>,
        Dave Chinner <>,
        Andrew Morton <>,,
        Linux Kernel Mailing List <>,
        Jeff Layton <>,
        Thomas Gleixner <>,
        Linux-MM <>,
        "open list:NFS, SUNRPC, AND..." <>,
        "Theodore Ts'o" <>, Al Viro <>,
        Ext4 Developers List <>,
        Amir Goldstein <>,
        linux-btrfs <>,
        linux-fsdevel <>,
        Andreas Dilger <>,
        Kent Overstreet <>,
        Stephen Boyd <>,
        David Howells <>, Jan Kara <>
Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain
 timestamp handing

On Wed, Nov 1, 2023, 11:35 Trond Myklebust <> wrote:
> My client writes to the file and immediately reads the ctime. A 3rd
> party client then writes immediately after my ctime read.
> A reboot occurs (maybe minutes later), then I re-read the ctime, and
> get the same value as before the 3rd party write.
> Yes, most of the time that is better than the naked ctime, but not
> across a reboot.

Ahh, I knew I was missing something.

But I think it's fixable, with an additional rule:

 - when generating STATX_CHANGE_COOKIE, if the ctime matches the
current time and the ctime counter is zero, set the ctime counter to

That means that you will have *spurious* cache invalidations of such
cached data after a reboot, but only for reads that happened right
after the file was written.

Now, it's obviously not unheard of to finish writing a file, and then
immediately reading the results again.

But at least those caches should be somewhat limited (and the problem
then only happens when the nfs server is rebooted).

I *assume* that the whole thundering herd issue with lots of clients
tends to be for stable files, not files that were just written and
then immediately cached?

I dunno. I'm sure there's still some thinko here.


Powered by blists - more mailing lists