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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 19 Oct 2022 08:18:15 -0400 From: Jeff Layton <jlayton@...nel.org> To: Christian Brauner <brauner@...nel.org> Cc: tytso@....edu, adilger.kernel@...ger.ca, djwong@...nel.org, 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, 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? -- Jeff Layton <jlayton@...nel.org>
Powered by blists - more mailing lists