Re: [RFC PATCH 00/11] NFS/NFSD: nfs4_acl passthru for NFSv4 reexport

[Mike Snitzer <snitzer@kernel.org>]

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