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 4FEBE32D7DA for ; Thu, 19 Feb 2026 23:07:42 +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=1771542462; cv=none; b=qDDzcNUr3nAbj6yFxEWLFEAvX3AG2uHji2pVuMA4+1O+s+klh015ksxzD85nqLcGjHxqjPNBHuir5I0g5k5vEyDQaoutqGcu6ZzhH4jHvSYb0rmJTl36UaFGf7IKZuTNM2nl9Lbn/+fIa7grK++iDgJC71DrYnkJa2pJXbeO+bg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771542462; c=relaxed/simple; bh=Laff54AfrdYYBa6XghOeKWbISto5TPGzQ200q8/EngQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JVdPmjJS7a4uFVgaU4xf4bdX7CrvwQjMye0eyn8Jal52RRFHnxp752eLoBB/mwiN6WSj0S5GnjG0b6MDH/lO4N4awXxgp8G0DbHwSt3jmvfLJyART6LXUS3o43SRa0gzsRCozNnzZNP+U11F5QwRwzvv2HMpRS5mZbb2t4kSjz0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=n5s0rhyv; 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="n5s0rhyv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E537C4CEF7; Thu, 19 Feb 2026 23:07:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771542462; bh=Laff54AfrdYYBa6XghOeKWbISto5TPGzQ200q8/EngQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=n5s0rhyvCb3WioDp6ru9rCb/D1wfeGanWe/YA64ZPO1I7xIEaMU7Pt7y4r+1xaUPN qL0CPkiKbREMtSOVByKrTo/Uyb61LB4UAfSJWjA9CsbUpLuB5+kfjDMRXMMejGJUr8 i7+YNOiPoRpkIvoMMDXHqKnxqEVo2buHjmwZb5M5jmc6EkExEbTkUCqDa910lH0/Em BJrOzYuhKWW4T2GlBX2YqHVcbCAFz0/zoLIgvB/oZfkX4Orn/OLJTGCoBay/wjTL27 5wOaxFZkTj+jGrQhYSoufI/WnOBTroFX6l54BrvcpKJ3547Gd/bqgeTObpDASksiqy NxEZX/7SnPjCw== Date: Thu, 19 Feb 2026 18:07:40 -0500 From: Mike Snitzer To: Chuck Lever Cc: 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> <098b9502-8868-47c9-b164-be80bb11ae74@oracle.com> 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: <098b9502-8868-47c9-b164-be80bb11ae74@oracle.com> On Thu, Feb 19, 2026 at 05:21:06PM -0500, Chuck Lever wrote: > On 2/19/26 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. > > > > This patchset is marked as RFC because I expect there will be > > suggestions for possible NFSD implementation improvements. > > A couple of random observations: > > 1. I haven't been a fan of these double-subsystem patch sets. Is there > any way we can get this split into one set for NFSD and one for the NFS > client, with as little code sharing between the two as possible? Maybe a > pipe dream, I know. Open to suggestions, but the reexport nature of this patchset makes it tough for each half to be entirely standalone. As is, patches 1 - 8 could all land via NFSD. But the code would be dormant because no filesystems would set EXPORT_OP_NFSV4_ACL_PASSTHRU. NFS _could_ just apply patch 3 (so it'd duplicate NFSD's commit for patch 3) and then apply NFS patches 9 - 11. > 2. Do you have a plan for similar passthru support for the NFSv4.2 POSIX > draft ACL extension? Wasn't on my radar, but I know you and Rick have been busy getting NFSv4 POSIX draft ACL support to land in NFSD. I still have work ahead to understand all that you guys landed... but being POSIX I just paid attention to the mutual exclusion of your newer work versus nfs4_acl. Excuse my naivety but doesn't NFSD now provide support for NFSv4.2 POSIX draft ACL extension? So what's the usecase you're thinking passthru would be meaningful for? If you might provide some guidance on expected work items that'd help plant seeds. I can try to bone up on NFSv4.2 POSIX draft ACL extension and we could discuss further at Bake-a-thon? Relative to NFS v4.1 ACL passthru, Hammerspace needing to support 4.1 access for the benefit of kerberos usage made adding 4.1 ACL passthru to 4.2 a compelling feature/requirement to implement. Mike