From: Christoph Hellwig <hch@lst.de>
To: cel@kernel.org
Cc: linux-nfs@vger.kernel.org, Jeff Layton <jlayton@kernel.org>,
Neil Brown <neilb@suse.de>, Dai Ngo <dai.ngo@oracle.com>,
Olga Kornievskaia <kolga@netapp.com>, Tom Talpey <tom@talpey.com>,
Chuck Lever <chuck.lever@oracle.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v2] NFSD: Support write delegations in LAYOUTGET
Date: Wed, 12 Jun 2024 07:08:59 +0200 [thread overview]
Message-ID: <20240612050859.GA27147@lst.de> (raw)
In-Reply-To: <20240611193645.65792-2-cel@kernel.org>
On Tue, Jun 11, 2024 at 03:36:46PM -0400, cel@kernel.org wrote:
> From: Chuck Lever <chuck.lever@oracle.com>
>
> I noticed LAYOUTGET(LAYOUTIOMODE4_RW) returning NFS4ERR_ACCESS
> unexpectedly. The NFS client had created a file with mode 0444, and
> the server had returned a write delegation on the OPEN(CREATE). The
> client was requesting a RW layout using the write delegation stateid
> so that it could flush file modifications.
>
> Creating a read-only file does not seem to be problematic for
> NFSv4.1 without pNFS, so I began looking at NFSD's implementation of
> LAYOUTGET.
>
> The failure was because fh_verify() was doing a permission check as
> part of verifying the FH presented during the LAYOUTGET. It uses the
> loga_iomode value to specify the @accmode argument to fh_verify().
> fh_verify(MAY_WRITE) on a file whose mode is 0444 fails with -EACCES.
>
> To permit LAYOUT* operations in this case, add OWNER_OVERRIDE when
> checking the access permission of the incoming file handle for
> LAYOUTGET and LAYOUTCOMMIT.
This looks reasonable to me:
Reviewed-by: Christoph Hellwig <hch@lst.de>
next prev parent reply other threads:[~2024-06-12 5:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-11 19:36 [PATCH v2] NFSD: Support write delegations in LAYOUTGET cel
2024-06-12 5:08 ` Christoph Hellwig [this message]
2024-06-12 13:52 ` Jeff Layton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240612050859.GA27147@lst.de \
--to=hch@lst.de \
--cc=cel@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--cc=jlayton@kernel.org \
--cc=kolga@netapp.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=tom@talpey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.