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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 26 Sep 2023 16:29:12 +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

On Tue, Sep 26, 2023 at 08:51:32AM -0400, Jeff Layton wrote:
> On Tue, 2023-09-26 at 14:18 +0200, Christian Brauner wrote:
> > > > If there's no clear users and workloads depending on this other than for
> > > > the sake of NFS then we shouldn't expose this to userspace. We've tried
> > 
> > > 
> > > Some NFS servers run in userspace, and they would a "clear user" of this
> > > functionality.
> > 
> > See my comment above. We did thist mostly for the sake of NFS as there
> > was in itself nothing wrong with timestamps that needed urgent fixing.
> > 
> > The end result has been that we caused a regression for four other major
> > filesystems when they were switched to fine-grained timestamps.
> > 
> > So NFS servers in userspace isn't a sufficient argument to just try
> > again with a slightly tweaked solution but without a wholesale fix of
> > the actual ordering problem. The bar to merge this will naturally be
> > higher the second time around.
> > 
> > That's orthogonal to improving the general timestamp infrastructure in
> > struct inode ofc.
> 
> There are multiple proposals in flight here, and they all sort of
> dovetail on one another. I'm not proposing we expose any changes to the
> timestamps to users in any way, unless we can fix the ordering issues,
> and ensure that we can preserve existing behavior re: utimensat().

Yeah, I know you're aware of that and I'm mostly clarifying the
conditions for this work for the ones not that closely involved.

> I think it's possible to do that, but I'm going to table that work for
> the moment, and finish up the atime/mtime accessor conversions first.

That sounds great.

> That makes experimenting with all of this a lot simpler. I think I can

Oh that's good then.