From: Jeff Layton <jlayton@kernel.org>
To: tytso@mit.edu, adilger.kernel@dilger.ca, djwong@kernel.org,
david@fromorbit.com, trondmy@hammerspace.com, neilb@suse.de,
viro@zeniv.linux.org.uk, zohar@linux.ibm.com, xiubli@redhat.com,
chuck.lever@oracle.com, lczerner@redhat.com, jack@suse.cz,
bfields@fieldses.org, brauner@kernel.org, fweimer@redhat.com
Cc: linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, ceph-devel@vger.kernel.org,
linux-ext4@vger.kernel.org, linux-nfs@vger.kernel.org,
linux-xfs@vger.kernel.org
Subject: [PATCH v5 0/8] vfs/nfsd: clean up handling of the i_version counter
Date: Thu, 8 Sep 2022 13:24:40 -0400 [thread overview]
Message-ID: <20220908172448.208585-1-jlayton@kernel.org> (raw)
v5: don't try to expose i_version to userland (yet)
use getattr to get i_version in nfsd
take inode lock when getting i_version
This set is a bit different from the earlier ones. In particular, it
does not try to expose i_version to userland. STATX_INO_VERSION is added
as a kernel-only symbol (for now), and the infrastructure is changed
around to use it.
This allows us to fetch the i_version during the getattr operation, and
eliminate the fetch_iversion export operation. This is a much more
natual way to handle the i_version counter in nfsd and, as a bonus, this
should allow nfsd to use ceph's i_version counter too. Huzzah!
The first two patches fix up ext4's i_version handling and enable it
unconditionally. Those can go in independently of the rest, IMO. Ted, if
you're ok with those and want to pick them up then that would be great.
The rest of the patches clean up the i_version handling, but should not
change the userland API at all. This should make it very simple to
expose i_version to userland in the future if we decide to do so. Maybe
we should take these in via the nfsd tree? I'm not sure here.
The last patch should be considered an RFC. I think that that approach
should prevent the potential race, without adding new work in the
write codepath.
Jeff Layton (8):
iversion: clarify when the i_version counter must be updated
ext4: fix i_version handling in ext4
ext4: unconditionally enable the i_version counter
vfs: plumb i_version handling into struct kstat
nfs: report the inode version in getattr if requested
ceph: report the inode version in getattr if requested
nfsd: use the getattr operation to fetch i_version
nfsd: take inode_lock when querying for NFSv4 GETATTR
fs/ceph/inode.c | 14 +++++++++-----
fs/ext4/inode.c | 15 +++++----------
fs/ext4/ioctl.c | 4 ++++
fs/ext4/move_extent.c | 6 ++++++
fs/ext4/super.c | 13 ++++---------
fs/ext4/xattr.c | 1 +
fs/nfs/export.c | 7 -------
fs/nfs/inode.c | 7 +++++--
fs/nfsd/nfs4xdr.c | 17 ++++++++++++++++-
fs/nfsd/nfsfh.c | 6 ++++++
fs/nfsd/nfsfh.h | 9 ++++-----
fs/nfsd/vfs.h | 7 ++++++-
fs/stat.c | 14 +++++++++++++-
include/linux/exportfs.h | 1 -
include/linux/iversion.h | 10 ++++++++--
include/linux/stat.h | 4 ++++
16 files changed, 91 insertions(+), 44 deletions(-)
--
2.37.3
next reply other threads:[~2022-09-08 17:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 17:24 Jeff Layton [this message]
2022-09-08 17:24 ` [PATCH v5 1/8] iversion: clarify when the i_version counter must be updated Jeff Layton
2022-09-08 17:24 ` [PATCH v5 2/8] ext4: fix i_version handling in ext4 Jeff Layton
2022-09-30 1:22 ` Theodore Ts'o
2022-09-08 17:24 ` [PATCH v5 3/8] ext4: unconditionally enable the i_version counter Jeff Layton
2022-09-08 17:24 ` [PATCH v5 4/8] vfs: plumb i_version handling into struct kstat Jeff Layton
2022-09-08 17:24 ` [PATCH v5 5/8] nfs: report the inode version in getattr if requested Jeff Layton
2022-09-08 17:24 ` [PATCH v5 6/8] ceph: " Jeff Layton
2022-09-08 17:24 ` [PATCH v5 7/8] nfsd: use the getattr operation to fetch i_version Jeff Layton
2022-09-08 17:24 ` [RFC PATCH v5 8/8] nfsd: take inode_lock when querying for NFSv4 GETATTR Jeff Layton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220908172448.208585-1-jlayton@kernel.org \
--to=jlayton@kernel.org \
--cc=adilger.kernel@dilger.ca \
--cc=bfields@fieldses.org \
--cc=brauner@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=chuck.lever@oracle.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=fweimer@redhat.com \
--cc=jack@suse.cz \
--cc=lczerner@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=trondmy@hammerspace.com \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=xiubli@redhat.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.