Re: [PATCH rfc 2/2] NFSD: allow client to use write delegation stateid for READ

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 7/27/24 12:33 PM, Sagi Grimberg wrote:
id(cstate, &u->write.wr_stateid);
   }
+/**
+ * nfsd4_deleg_read_conflict - Recall if read causes conflict
+ * @rqstp: RPC transaction context
+ * @clp: nfs client
+ * @fhp: nfs file handle
+ * @inode: file to be checked for a conflict
+ * @modified: return true if file was modified
+ * @size: new size of file if modified is true
+ *
+ * This function is called when there is a conflict between a write
+ * delegation and a read that is using a special stateid where the
+ * we cannot derive the client stateid exsistence. The server
+ * must recall a conflicting delegation before allowing the read
+ * to continue.
+ *
+ * Returns 0 if there is no conflict; otherwise an nfs_stat
+ * code is returned.
+ */
+__be32 nfsd4_deleg_read_conflict(struct svc_rqst *rqstp,
+        struct nfs4_client *clp, struct svc_fh *fhp)
+{
+    struct nfs4_file *fp;
+    __be32 status = 0;
+
+    fp = nfsd4_file_hash_lookup(fhp);
+    if (!fp)
+        return nfs_ok;
+
+    spin_lock(&state_lock);
+    spin_lock(&fp->fi_lock);
+    if (!list_empty(&fp->fi_delegations) &&
+        !nfs4_delegation_exists(clp, fp)) {
+        /* conflict, recall deleg */
I don't see how we can have a delegation conflict here. If a client
has a write delegation then there should not be any delegations from
other clients.
A delegation conflict is possible if the client is using an
anonymous stateid to perform the READ.

Then we should not detect any delegation conflict from this
function.

Can you explain why?

It was my mistake. I missed the part that the nfsd4_deleg_read_conflict
was called only from the context of the client sending the read with the
special stateid.

It's probably clearer to separate this patch into 2 patches: one to allow
a write delegation (opened with wr-only) to read the file and the other
is to detect write delegation conflict, regardless of whether the delegation
was from an open with rw or wr-only, when a special stateid is used to
do the read.

-Dai


If the client sent a raed with anon stateid, this function checks the pending delegations (fi_delegations), and not from the same client (!nfs4_delegation_exists),
then it should detect a conflict.



One thing we could perhaps do is add support for the use of
anonymous stateids as a separate patch.

This would be a separate issue from allowing write delegation
stateid to read. This would be to detect the scenario where a
client using special stateid to read while another client has
a write delegation on the file.

As mentioned, I can separate it, but this would make this patch
break a pynfs test.




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux