On Tue, Nov 17, 2020 at 10:34:57AM -0500, Jeff Layton wrote: > On Tue, 2020-11-17 at 10:26 -0500, J. Bruce Fields wrote: > > On Tue, Nov 17, 2020 at 07:34:49AM -0500, Jeff Layton wrote: > > > I don't think I described what I was thinking well. Let me try again... > > > > > > There should be no need to change the code in iversion.h -- I think we > > > can do this in a way that's confined to just nfsd/export code. > > > > > > What I would suggest is to have nfsd4_change_attribute call the > > > fetch_iversion op if it exists, instead of checking IS_I_VERSION and > > > doing the stuff in that block. If fetch_iversion is NULL, then just use > > > the ctime. > > > > > > Then, you just need to make sure that the filesystems' export_ops have > > > an appropriate fetch_iversion vector. xfs, ext4 and btrfs can just call > > > inode_query_iversion, and NFS and Ceph can call inode_peek_iversion_raw. > > > The rest of the filesystems can leave fetch_iversion as NULL (since we > > > don't want to use it on them). > > > > Thanks for your patience, that makes sense, I'll try it. > > > > There is one gotcha in here though... ext4 needs to also handle the case > where SB_I_VERSION is not set. The simple fix might be to just have > different export ops for ext4 based on whether it was mounted with -o > iversion or not, but maybe there is some better way to do it? I was thinking ext4's export op could check for I_VERSION on its own and vary behavior based on that. I'll follow up with new patches in a moment. I think the first one's all that's needed to fix the problem Daire identified. I'm a little less sure of the rest. Lightly tested, just by running them through my usual regression tests (which don't re-export) and then running connectathon on a 4.2 re-export of a 4.2 mount. The latter triggered a crash preceded by a KASAN use-after free warning. Looks like it might be a problem with blocking lock notifications, probably not related to these patches. --b.
