On Fri, Mar 13, 2020 at 04:07:02PM +0000, Frank van der Linden wrote: > On Fri, Mar 13, 2020 at 11:35:49AM -0400, J. Bruce Fields wrote: > > > > > > On Wed, Mar 11, 2020 at 07:59:42PM +0000, Frank van der Linden wrote: > > > Second, RFC 8276 (NFSv4 extended attribute support) specifies that > > > delegations should be recalled (8.4.2.4, 8.4.4.4) when a SETXATTR > > > or REMOVEXATTR operation is performed. So, like with other fs > > > operations, try to break the delegation. The _locked version of > > > these operations will not wait for the delegation to be successfully > > > broken, instead returning an error if it wasn't, so that the NFS > > > server code can return NFS4ERR_DELAY to the client (similar to > > > what e.g. vfs_link does). > > > > Is there a preexisting bug here? Even without NFS support for xattrs, a > > local setxattr on the filesystem should still revoke any delegations > > held by remote NFS clients. I couldn't tell whether we're getting that > > right from a quick look at the current code. > > > > --b. > > I think there's currently a bug if that's the expected behavior, yes. > Attribute changes will call notify_change(), and other methods (unlink, > link, rename) call try_break_deleg(). But the xattr entry points > don't do that, which is why I added it. Got it, thanks. In that case I'd move this patch (or the part of it required to fix that bug) to the front of the series and add a Cc: stable@xxxxxxxxxxxxxxx --b.
