linux-kernel - Re: [PATCH v7 0/9] fs: clean up handling of i

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]

Message-ID: <20221020065813.sdnrerbrvi75xlkp@wittgenstein>
Date:   Thu, 20 Oct 2022 08:58:13 +0200
From:   Christian Brauner <brauner@...nel.org>
To:     Jeff Layton <jlayton@...nel.org>
Cc:     "Darrick J. Wong" <djwong@...nel.org>, tytso@....edu,
        adilger.kernel@...ger.ca, david@...morbit.com,
        trondmy@...merspace.com, neilb@...e.de, viro@...iv.linux.org.uk,
        zohar@...ux.ibm.com, xiubli@...hat.com, chuck.lever@...cle.com,
        lczerner@...hat.com, jack@...e.cz, bfields@...ldses.org,
        fweimer@...hat.com, linux-btrfs@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        ceph-devel@...r.kernel.org, linux-ext4@...r.kernel.org,
        linux-nfs@...r.kernel.org, linux-xfs@...r.kernel.org
Subject: Re: [PATCH v7 0/9] fs: clean up handling of i_version counter

On Wed, Oct 19, 2022 at 04:36:47PM -0400, Jeff Layton wrote:
> On Wed, 2022-10-19 at 08:45 -0700, Darrick J. Wong wrote:
> > On Wed, Oct 19, 2022 at 08:18:15AM -0400, Jeff Layton wrote:
> > > On Wed, 2022-10-19 at 13:13 +0200, Christian Brauner wrote:
> > > > On Mon, Oct 17, 2022 at 06:57:00AM -0400, Jeff Layton wrote:
> > > > > This patchset is intended to clean up the handling of the i_version
> > > > > counter by nfsd. Most of the changes are to internal interfaces.
> > > > > 
> > > > > This set is not intended to address crash resilience, or the fact that
> > > > > the counter is bumped before a change and not after. I intend to tackle
> > > > > those in follow-on patchsets.
> > > > > 
> > > > > My intention is to get this series included into linux-next soon, with
> > > > > an eye toward merging most of it during the v6.2 merge window. The last
> > > > > patch in the series is probably not suitable for merge as-is, at least
> > > > > until we sort out the semantics we want to present to userland for it.
> > > > 
> > > > Over the course of the series I struggled a bit - and sorry for losing
> > > > focus - with what i_version is supposed to represent for userspace. So I
> > > > would support not exposing it to userspace before that. But that
> > > > shouldn't affect your other changes iiuc.
> > > 
> > > Thanks Christian,
> > > 
> > > It has been a real struggle to nail this down, and yeah I too am not
> > > planning to expose this to userland until we have this much better
> > > defined. Patch #9 is just to give you an idea of what this would
> > > ultimately look like. I intend to re-post the first 8 patches with an
> > > eye toward merge in v6.2, once we've settled on the naming. On that
> > > note...
> > > 
> > > I believe you had mentioned that you didn't like STATX_CHANGE_ATTR for
> > > the name, and suggested STATX_I_VERSION (or something similar), which I
> > > later shortened to STATX_VERSION.
> > > 
> > > Dave C. objected to STATX_VERSION, as "version" fields in a struct
> > > usually refer to the version of the struct itself rather than the
> > > version of the thing it describes. It also sort of implies a monotonic
> > > counter, and I'm not ready to require that just yet.
> > > 
> > > What about STATX_CHANGE for the name (with corresponding names for the
> > > field and other flags)? That drops the redundant "_ATTR" postfix, while
> > > being sufficiently vague to allow for alternative implementations in the
> > > future.
> > > 
> > > Do you (or anyone else) have other suggestions for a name?
> > 
> > Welllll it's really a u32 whose value doesn't have any intrinsic meaning
> > other than "if (value_now != value_before) flush_cache();" right?
> > I think it really only tracks changes to file data, right?
> > 
> 
> It's a u64, but yeah, you're not supposed to assign any intrinsic
> meaning to the value itself.
> 
> > STATX_CHANGE_COOKIE	(wait, does this cookie augment i_ctime?)
> > 
> > STATX_MOD_COOKIE	(...or just file modifications/i_mtime?)
> > 
> > STATX_MONITOR_COOKIE	(...what are we monitoring??)
> > 
> > STATX_MON_COOKIE
> > 
> > STATX_COOKIE_MON
> > 
> > STATX_COOKIE_MONSTER
> > 
> > There we go. ;)
> > 
> > In seriousness, I'd probably go with one of the first two.  I wouldn't
> > be opposed to the last one, either, but others may disagree. ;)
> > 
> > --D
> > 
> > 
> 
> STATX_CHANGE_COOKIE is probably the best one. I'll plan to go with that
> unless someone has a better idea. Thanks for the suggestions!

Sounds fine to me.