Re: [PATCH 02/14] xattr: modify vfs_{set, remove}xattr for NFS server use

J. Bruce Fields
2020-03-13T21:06:07Z

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@vger.kernel.org

--b.