Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
IronPort-SDR: QprfF84xfmk4eZzeW+mz6/8I8dCVQESW9VHPlMivnWoT6AiljdD092VXBuaIiFbW7mz7WoN9xV
 wDAktcRJ3Q0w==
Date:   Tue, 5 Nov 2019 00:06:11 +0000
From:   Frank van der Linden <fllinden@amazon.com>
To:     Bruce Fields <bfields@fieldses.org>
CC:     Chuck Lever <chucklever@gmail.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC PATCH 00/35] user xattr support (RFC8276)
Message-ID: <20191105000352.GA24610@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com>
References: <cover.1568309119.git.fllinden@amazon.com>
 <9CAEB69A-A92C-47D8-9871-BA6EA83E1881@gmail.com>
 <20191024231547.GA16466@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com>
 <18D2845F-27FF-4EDF-AB8A-E6051FA03DF0@gmail.com>
 <20191104030132.GD26578@fieldses.org>
 <358420D8-596E-4D3B-A01C-DACB101F0017@gmail.com>
 <20191104162147.GA31399@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com>
 <20191104225846.GA13469@fieldses.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20191104225846.GA13469@fieldses.org>
User-Agent: Mutt/1.11.4 (2019-03-13)
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On Mon, Nov 04, 2019 at 05:58:46PM -0500, Bruce Fields wrote:
> Just checking code for other filesystems quickly; if I understand right:
> 
> 	- ext4 has user_xattr and nouser_xattr options, but you get a
> 	  deprecation warning if you try to use the latter;
> 	- xfs doesn't support either option;
> 	- cifs supports both, with xattr support the default.
> 
> Not necessarily my call, but just for simplicity's sake, I'd probably
> leave out the option and see if anybody complains.

Sounds good, I'll go with that.
> 
> > Also, currently, my code does not fail the mount operation if user xattrs
> > are asked for, but the server does not support them. It just doesn't
> > set NFS_CAP_XATTR for the server, and the xattr handler entry points
> > eturn -EOPNOTSUPP, as they check for NFS_CAP_XATTR. What's the preferred
> > behavior there?
> 
> getxattr(2) under ERRORS says:
> 
> 	ENOTSUP
> 	      Extended attributes are not supported by the filesystem,
> 	      or  are disabled.
> 
> so I'm guessing just erroring out is clearest.
> 
> I also see there's an EOPNOTSUPP return in the nouser_xattr case in
> ext4_xattr_user_get.  (errno(3) says ENOTSUP and EOPNOTSUPP are the same
> value on Linux.)

Sure. So, to recap, here's what I'll do:

* Remove the CONFIG options - enable the code by default.
* Server side:
	* Remove the export file option to not export extended attributes
* Client side:
	* Always probe user xattr support, and use it when available
	  (returning EOPNOTSUPP, as expected, for all xattr syscalls if
	   it is not available).

Thanks for the feedback so far - much appreciated. I'll submit the separate
client and server patch sets this week.

- Frank