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, 7 Sep 2022 07:33:13 -0400 From: Jeff Layton <jlayton@...nel.org> To: 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, brauner@...nel.org, fweimer@...hat.com Cc: linux-api@...r.kernel.org, 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, Colin Walters <walters@...bum.org> Subject: [PATCH v4 1/6] iversion: update comments with info about atime updates The i_version field in the kernel has had different semantics over the decades, but we're now proposing to expose it to userland via statx. This means that we need a clear, consistent definition of what it means and when it should change. Update the comments in iversion.h to describe when the i_version must change. Cc: Colin Walters <walters@...bum.org> Cc: NeilBrown <neilb@...e.de> Cc: Trond Myklebust <trondmy@...merspace.com> Cc: Dave Chinner <david@...morbit.com> Link: https://lore.kernel.org/linux-xfs/166086932784.5425.17134712694961326033@noble.neil.brown.name/#t Signed-off-by: Jeff Layton <jlayton@...nel.org> --- include/linux/iversion.h | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/include/linux/iversion.h b/include/linux/iversion.h index 3bfebde5a1a6..0555a3851dbf 100644 --- a/include/linux/iversion.h +++ b/include/linux/iversion.h @@ -9,8 +9,14 @@ * --------------------------- * The change attribute (i_version) is mandated by NFSv4 and is mostly for * knfsd, but is also used for other purposes (e.g. IMA). The i_version must - * appear different to observers if there was a change to the inode's data or - * metadata since it was last queried. + * appear larger to observers if there was an explicit change to the inode's + * data or metadata since it was last queried. + * + * An explicit change is one that would ordinarily result in a change to the + * inode status change time (aka ctime). i_version must appear to change, even + * if the ctime does not (since the whole point is to avoid missing updates due + * to timestamp granularity). If POSIX mandates that the ctime must change due + * to an operation, then the i_version counter must be incremented as well. * * Observers see the i_version as a 64-bit number that never decreases. If it * remains the same since it was last checked, then nothing has changed in the -- 2.37.3
Powered by blists - more mailing lists