linux-kernel - Re: [PATCH v8 0/5] fs: multigrain timestamps for XFS's change

lists.openwall.net		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:   Tue, 26 Sep 2023 14:10:54 +0200
From:   Christian Brauner <brauner@...nel.org>
To:     Jeff Layton <jlayton@...nel.org>
Cc:     NeilBrown <neilb@...e.de>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Chuck Lever <chuck.lever@...cle.com>,
        Olga Kornievskaia <kolga@...app.com>,
        Dai Ngo <Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>,
        Chandan Babu R <chandan.babu@...cle.com>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Dave Chinner <david@...morbit.com>, Jan Kara <jack@...e.cz>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Kent Overstreet <kent.overstreet@...ux.dev>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-nfs@...r.kernel.org, linux-xfs@...r.kernel.org
Subject: Re: [PATCH v8 0/5] fs: multigrain timestamps for XFS's change_cookie

> > Some NFS servers run in userspace, and they would a "clear user" of this
> > functionality.
> > 
> 
> Indeed. Also, all of the programs that we're concerned about breaking
> here (make, rsync, etc.) could benefit from proper fine-grained
> timestamps:
> 
> Today, when they see two identical timestamps on files, these programs
> have to assume the worst: rsync has to do the copy, make has to update
> the target, etc. With a real distinguishable fine-grained timestamps,
> these programs would likely be more efficient and some of these unneeded
> operations would be avoided.

The whole sales pitch falls flat if we end up with wrong ordering of
timestamps which caused us to revert this. So unless this is fixed
we shouldn't expose this to userspace again.