| Message ID | 20231027015613.26247-1-neilb@suse.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | support admin-revocation of v4 state | expand |
On Sat, Oct 28, 2023 at 09:10:19AM +1100, NeilBrown wrote: > On Sat, 28 Oct 2023, Chuck Lever wrote: > > On Fri, Oct 27, 2023 at 12:45:28PM +1100, NeilBrown wrote: > > > This is a revised version of a patch set I sent over a year ago. > > > It now supports v4.0 and has had more testing. > > > > > > There are cirsumstances where an admin might need to unmount a > > > filesystem that is NFS-exported and in active use, but does not want to > > > stop the NFS server completely. These are certainly unusual > > > circumstance and doing this might negatively impact any clients acting > > > on the filesystem, but the admin should be able to do this. > > > > > > Currently this is quite possible for for NFSv3. Unexporting the > > > filesystem will ensure no new opens happen, and writing the path name to > > > /proc/fs/nfsd/unlock_filesystem will ensure anly NLM locks held in the > > > filesystem are released so that NFSD no longer prevents the filesystem > > > from being unlocked. > > > > > > It is not currently possible for NFSv4. Writing to unlock_filesystem > > > does not affect NFSv4, which is arguably a bug. This series fixes the bug. > > > > I agree that this is a good thing to do. > > > > However, I'd like to migrate the "unlock_filesystem" functionality > > to the nfsd netlink protocol first rather than adding this support > > to /proc/fs/nfsd/. I don't believe that would be a difficult pre- > > requisite to get through. > > > > Does that seem sensible? > > Not to me. > > This is not new functionality - it is a fix for existing functionality > which incorrectly ignores NFSv4. It's arguable whether this counts as new functionality. I can see both sides of that argument. For now let's agree to call it a fix, and let's say it would therefore be appropriate for, say, an -rc pull request (although I think it will land in nfsd-next for v6.8). So, on first read through these patches, for some reason I had the impression that you were adding another file under /proc/fs/nfsd. That's what I would like to avoid at this point. Changing the values that can appear in one of these files is an area that is somewhat more grey. I'm willing to be flexible about that for now. > When you say "migrate" I hope you mean to add the "unlock_filesystem" > functionality to netlink, but not remove it from /proc/fs/nfsd for > several years at least. I certainly wouldn't want to wait several > (more) years for this to land. Naturally. We are playing by the usual rules about kernel-user space API deprecation. But there's always a fine line about whether an about-to-be-deprecated API should get new functionality or even bug fixes. > However it lands, the interface that it used for NFSv3 should be the > same as the interface that is used for NFSv4 and I think > /proc/fs/nfsd/unlock_filesystem should be one such interface until (if > ever) we discard the /proc/fs/nfsd filesystem. Fair enough. It wasn't clear to me before that the new state types described below will not be exposed through the existing unlock_filesystem interface. If Jeff agrees, I can pull this into v6.8. > > > For NFSv4.1 and later code is straight forward. We add new state types > > > for admin-revoked state (open, lock, deleg) and change the type of any > > > state on a filesystem - inavlidating any access and closing files as we > > > go. While there are any revoked states we report this to the client in > > > the response to SEQUENCE requests, and it will check and free any states > > > that need to be freed. > > > > > > For NFSv4.0 it isn't quite so easy as there is no mechanism for the > > > client to explicitly acknowledged admin-revoked states. The approach > > > this patchset takes is to discard NFSv4.0 admin-revoked states one > > > lease-time after they were revoked, or immediately for a state that the > > > client tryies to use and gets an "ADMIN_REVOKED" error for. If the > > > filestystem has been unmounted (as expected), the client will see STATE > > > errors before it has a chance to see ADMIN_REVOKED errors, so most often > > > the timeout will be how states are discarded. > > > > > > NeilBrown > > > > > > [PATCH 1/6] nfsd: prepare for supporting admin-revocation of state > > > [PATCH 2/6] nfsd: allow admin-revoked state to appear in > > > [PATCH 3/6] nfsd: allow admin-revoked NFSv4.0 state to be freed. > > > [PATCH 4/6] nfsd: allow lock state ids to be revoked and then freed > > > [PATCH 5/6] nfsd: allow open state ids to be revoked and then freed > > > [PATCH 6/6] nfsd: allow delegation state ids to be revoked and then > > > > > > > -- > > Chuck Lever > > >