From: dai.ngo@oracle.com
To: Chuck Lever <cel@kernel.org>
Cc: chuck.lever@oracle.com, jlayton@kernel.org,
linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v5 2/3] NFSD: handle GETATTR conflict with write delegation
Date: Mon, 22 May 2023 23:02:48 -0700 [thread overview]
Message-ID: <4eda21d1-bc9c-ae1e-009b-c868dd18abce@oracle.com> (raw)
In-Reply-To: <ZGwoXtYZP0Z0JgAf@manet.1015granger.net>
On 5/22/23 7:43 PM, Chuck Lever wrote:
> On Mon, May 22, 2023 at 04:52:39PM -0700, Dai Ngo wrote:
>> If the GETATTR request on a file that has write delegation in effect
>> and the request attributes include the change info and size attribute
>> then the write delegation is recalled and NFS4ERR_DELAY is returned
>> for the GETATTR.
> Isn't this yet another case where the server should send the
> CB_RECALL and wait for it briefly, before resorting to
> NFS4ERR_DELAY?
Think about this more, I don't think we even need to recall the
delegation at all. The Linux client does not flush the dirty file
data before returning the delegation so the GETATTR still get stale
attributes at the server. And the spec is not explicitly requires
the delegation to be recalled.
If we want to provide the client with more accurate file attributes
then we need to use the CB_GETATTR to get the up-to-date change info
and file size from the client. I think we agreed to defer this for later.
>
>
>> Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
>> ---
>> fs/nfsd/nfs4state.c | 37 +++++++++++++++++++++++++++++++++++++
>> fs/nfsd/nfs4xdr.c | 5 +++++
>> fs/nfsd/state.h | 3 +++
>> 3 files changed, 45 insertions(+)
>>
>> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
>> index b90b74a5e66e..ea9cd781db5f 100644
>> --- a/fs/nfsd/nfs4state.c
>> +++ b/fs/nfsd/nfs4state.c
>> @@ -8353,3 +8353,40 @@ nfsd4_get_writestateid(struct nfsd4_compound_state *cstate,
>> {
>> get_stateid(cstate, &u->write.wr_stateid);
>> }
>> +
>> +__be32
>> +nfs4_handle_wrdeleg_conflict(struct svc_rqst *rqstp, struct inode *inode)
need to change this function name to nfsd4_deleg_getattr_conflict.
> As a globally-visible function, this needs a documenting comment, and
> please use "nfsd4_" rather than "nfs4_".
will fix, if we decide to do the recall.
-Dai
>
>
>> +{
>> + struct file_lock_context *ctx;
>> + struct file_lock *fl;
>> + struct nfs4_delegation *dp;
>> +
>> + ctx = locks_inode_context(inode);
>> + if (!ctx)
>> + return 0;
>> + spin_lock(&ctx->flc_lock);
>> + list_for_each_entry(fl, &ctx->flc_lease, fl_list) {
>> + if (fl->fl_flags == FL_LAYOUT ||
>> + fl->fl_lmops != &nfsd_lease_mng_ops)
>> + continue;
>> + if (fl->fl_type == F_WRLCK) {
>> + dp = fl->fl_owner;
>> + /*
>> + * increment the sc_count to prevent the delegation to
>> + * be freed while sending the CB_RECALL. The refcount is
>> + * decremented by nfs4_put_stid in nfsd4_cb_recall_release
>> + * after the request was sent.
>> + */
>> + if (dp->dl_recall.cb_clp == *(rqstp->rq_lease_breaker) ||
>> + !refcount_inc_not_zero(&dp->dl_stid.sc_count)) {
>> + spin_unlock(&ctx->flc_lock);
>> + return 0;
>> + }
>> + spin_unlock(&ctx->flc_lock);
>> + return nfserrno(nfsd_open_break_lease(inode, NFSD_MAY_READ));
>> + }
>> + break;
>> + }
>> + spin_unlock(&ctx->flc_lock);
>> + return 0;
>> +}
>> diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
>> index 76db2fe29624..ed09b575afac 100644
>> --- a/fs/nfsd/nfs4xdr.c
>> +++ b/fs/nfsd/nfs4xdr.c
>> @@ -2966,6 +2966,11 @@ nfsd4_encode_fattr(struct xdr_stream *xdr, struct svc_fh *fhp,
>> if (status)
>> goto out;
>> }
>> + if (bmval0 & (FATTR4_WORD0_CHANGE | FATTR4_WORD0_SIZE)) {
>> + status = nfs4_handle_wrdeleg_conflict(rqstp, d_inode(dentry));
>> + if (status)
>> + goto out;
>> + }
>>
>> err = vfs_getattr(&path, &stat,
>> STATX_BASIC_STATS | STATX_BTIME | STATX_CHANGE_COOKIE,
>> diff --git a/fs/nfsd/state.h b/fs/nfsd/state.h
>> index d49d3060ed4f..64727a39f0db 100644
>> --- a/fs/nfsd/state.h
>> +++ b/fs/nfsd/state.h
>> @@ -732,4 +732,7 @@ static inline bool try_to_expire_client(struct nfs4_client *clp)
>> cmpxchg(&clp->cl_state, NFSD4_COURTESY, NFSD4_EXPIRABLE);
>> return clp->cl_state == NFSD4_EXPIRABLE;
>> }
>> +
>> +extern __be32 nfs4_handle_wrdeleg_conflict(struct svc_rqst *rqstp,
>> + struct inode *inode);
>> #endif /* NFSD4_STATE_H */
>> --
>> 2.9.5
>>
next prev parent reply other threads:[~2023-05-23 6:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-22 23:52 [PATCH v5 0/3] NFSD: add support for NFSv4 write delegation Dai Ngo
2023-05-22 23:52 ` [PATCH v5 1/3] NFSD: enable support for " Dai Ngo
2023-05-24 15:08 ` Jeff Layton
2023-05-22 23:52 ` [PATCH v5 2/3] NFSD: handle GETATTR conflict with " Dai Ngo
2023-05-23 2:43 ` Chuck Lever
2023-05-23 6:02 ` dai.ngo [this message]
2023-05-24 17:51 ` Chuck Lever III
2023-05-24 15:07 ` Jeff Layton
2023-05-24 17:49 ` dai.ngo
2023-05-25 17:21 ` Chuck Lever III
2023-05-22 23:52 ` [PATCH v5 3/3] locks: allow support for " Dai Ngo
2023-05-24 15:08 ` Jeff Layton
2023-05-24 15:09 ` Chuck Lever III
2023-05-24 16:55 ` Jeff Layton
2023-05-24 17:41 ` Chuck Lever III
2023-05-24 18:05 ` dai.ngo
2023-05-24 19:03 ` Jeff Layton
2023-05-24 20:27 ` dai.ngo
2023-05-24 17:52 ` dai.ngo
2023-06-12 16:14 ` [PATCH v5 0/3] NFSD: add support for NFSv4 " Chuck Lever III
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=4eda21d1-bc9c-ae1e-009b-c868dd18abce@oracle.com \
--to=dai.ngo@oracle.com \
--cc=cel@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).