From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C954E352F87 for ; Sun, 22 Feb 2026 19:39:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771789165; cv=none; b=qJGKNg6zjCtv6RyIPBzo5vZCViow6ugzY2WeNISnVzkNn+4Bx/CU0UWBssphYdCCgUcN5+cZciDO7xuPArAEDrBpNS5FSPHYHbtV0Z0MXhpP7Wf/yCvCw3v3ZD+S7GgFQ56T8PD1dpSMc9jgBoC3djFisGqSxKWUr+53ubTWLKU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771789165; c=relaxed/simple; bh=UILP1dam8BKBhG81q+Pp2jFcItIkY1H/ScQ93PjDYrc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hpchaVuX8zExaM9U0tMUD386UPe9wk+rF4ag3yDqnn1wmePRtvsPWBaVrcuxc9dzROfgwa4zubCl/oMZROzyOdJhDNQF7mr/Fz7g71wbf/lcye8kDk/DBU0yO48Fzr8YK/Vr4xJ1G2OE/Wrh80sLkagRvkHuvO9upM08nlcqBBg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FRsfQ8Ga; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FRsfQ8Ga" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C541C116D0; Sun, 22 Feb 2026 19:39:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771789165; bh=UILP1dam8BKBhG81q+Pp2jFcItIkY1H/ScQ93PjDYrc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FRsfQ8Ga0pF1qhUFZnY94zqwY3qMpIo+s/AxZFexKqGDSo27j4CAIU5Iakckj/JxM BrOrs9fTEK/tgMQ9HgcVVQR0aZUsB0Z3krdBY406oLVU3wvnbBLL3khObiEiuJ9A8t GvXhxUpuI1WriyKVmb84sz4q6A5/ky31YPIHAhZJykKwO/hlezvxVWDRfjA88NUHsS Fz6LyRtOcKIyvp/PeUj5KbKKI/E3ahG2iRMcr3HPgJo04TbwLFI+6O1ZaTrd56qlHE zoEyAIevzG2AdSqGb3ZdcJTdN1w+K4j/hcXUMwdllsn4KAAI9uApnbgYFs5YzC87Qa cBrw74g2JB1jw== Date: Sun, 22 Feb 2026 14:39:24 -0500 From: Mike Snitzer To: Chuck Lever Cc: Chuck Lever , Jeff Layton , Trond Myklebust , Anna Schumaker , linux-nfs@vger.kernel.org Subject: Re: [RFC PATCH 00/11] NFS/NFSD: nfs4_acl passthru for NFSv4 reexport Message-ID: References: <20260219221352.40554-1-snitzer@kernel.org> Precedence: bulk X-Mailing-List: linux-nfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sun, Feb 22, 2026 at 12:53:14PM -0500, Chuck Lever wrote: > > > On Thu, Feb 19, 2026, at 5:13 PM, Mike Snitzer wrote: > > Hi, > > > > This patchset aims to enable NFS v4.1 ACLs to be fully supported from > > an NFS v4.1 client to an NFSD v4.1 export that reexports NFS v4.2 > > filesystem which has full support for NFS v4.1 ACLs (DACL and SACL). > > > > The first 6 patches focus on nfs4_acl passthru enablement (primarily > > for NFSD), patch 7 adds 4.1 nfs4_acl passthru support (DACL and SACL), > > patch 8 optimizes particular nfs4_acl passthru implementation in NFSD > > to skip memcpy if nfs4_acl passthru isn't needed, patches 9-11 offer > > the corresponding required NFSv4 client changes. > > > > This work is based on the NFS and NFSD code that has been merged > > during the 7.0 merge window. > > Hey Mike, do you have a particular commit hash on which this series > applies? I've tried Torvalds master and nfsd-testing, and patch 3/11 > fails to apply to either of them. Sorry about that. It's closest baseline is nfsd-7.0 (but my tree is a frankenbeast starting at 6.12 sync'd all the way through to nfs-for-6.18-3 and nfsd-7.0), see: https://git.kernel.org/pub/scm/linux/kernel/git/snitzer/linux.git/log/?h=kernel-6.12.63/nfs4_acl-passthru Given what you found, I'm missing some of your latest conflicting changes. So it'll need a rebase. > > This patchset is marked as RFC because I expect there will be > > suggestions for possible NFSD implementation improvements. > > I think I understand the purpose of the series, and agree there is > an issue here. It doesn't look intractable to resolve. > > Wondering, though, if plumbing .setacl and .getacl through the > export ops is the right way to go. These seem like inode ops to > me, not export ops. Shouldn't they work like an inode's existing > POSIX ACL ops? I didn't even consider this. I'll have to take a closer look, but my intent was to convey that these interfaces are tightly coupled to NFSD for passthru purposes. Making them inode operations exposes the interface in a more generic way right? Is it useful to do _now_? If/when there is a need then they could be exposed as inode operations. How might doing that expose the interfaces to usage that was never intended or needed? Getting a bit into the weeds of design philosophy but I prefer to expose interfaces that cater to their immediate use. Put differently: I try not to game out hypotheticals too much. But I do welcome suggestions like this that offer experienced vision for being mindful of exposing interfaces that lend themselves to standing the test of time (more so than my scalpel approach anyway). Below you mention ZFS supports NFSv4 ACLs, how is that used? And does its usage offer a glimpse of some further hypothetical that is meaningful for Linux? > Second, I see this in one of the patch descriptions: "This 4.1 DACL > and SACL support is confined to NFSD's NFS reexport case (e.g. when > NFSD 4.1 reexports NFS 4.2)." It made me wonder -- is re-exporting > NFSv4.2 on an NFSv4.1 mount the only configuration that we want NFSD > to support? I would think that any combination of NFSv4 minor > versions could be supported. And if only a few combinations can be > supported, the cover letter or Documentation/ should explain why. My "(e.g. when NFSD 4.1 reexports NFS 4.2)" was only an example. The code should work fine with any NFSv4 combination -- though obviously 4.0 won't understand nfs4 acl utils --dacl and --sacl flags. > But really, I expect any file system type might be able to implement > NFSv4 ACLs (eg, ZFS does, but it's out-of-tree). I would like to > think about this in terms of "native file system NFSv4 ACL support" > rather than "NFSD pass through". So, the NFS client's NFSv4 inodes > have it, and this series doesn't need to add it anywhere else for > now. Sounds fine to frame it in those terms, but may cause make-work for some future consumer that'll never actually materialize. Relative to NFSD, its purely about passing through the nfs4_acl pages that it got off the wire directly down to FS that has "native file system NFSv4 ACL support". Thanks, Mike