| Message ID | 1741289493-15305-1-git-send-email-dai.ngo@oracle.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | NFSD: offer write delegation for OPEN with OPEN4_SHARE_ACCESS only | expand |
From: Chuck Lever <chuck.lever@oracle.com> On Thu, 06 Mar 2025 11:31:32 -0800, Dai Ngo wrote: > >From RFC8881 does not explicitly state that server must grant write > delegation to OPEN with OPEN4_SHARE_ACCESS_WRITE only. However there > are text in the RFC that implies it is up to the server implementation > to offer write delegation for OPEN with OPEN4_SHARE_ACCESS_WRITE only. > > Section 9.1.2: > > [...] Applied to nfsd-testing, thanks! V5 reverted, v6 applied. [1/1] NFSD: Offer write delegation for OPEN with OPEN4_SHARE_ACCESS_WRITE commit: ae73ee9fefa9e1d6c0e274c74d2ccf9d5e6ed2e5 -- Chuck Lever
From RFC8881 does not explicitly state that server must grant write delegation to OPEN with OPEN4_SHARE_ACCESS_WRITE only. However there are text in the RFC that implies it is up to the server implementation to offer write delegation for OPEN with OPEN4_SHARE_ACCESS_WRITE only. Section 9.1.2: "In the case of READ, the server may perform the corresponding check on the access mode, or it may choose to allow READ for OPEN4_SHARE_ACCESS_WRITE, to accommodate clients whose WRITE implementation may unavoidably do reads (e.g., due to buffer cache constraints)." Also in section 10.4.1 "Similarly, when closing a file opened for OPEN4_SHARE_ACCESS_WRITE/ OPEN4_SHARE_ACCESS_BOTH and if an OPEN_DELEGATE_WRITE delegation is in effect" When a write delegation is granted for OPEN with OPEN4_SHARE_ACCESS_WRITE, a new pair of nfsd_file and struct file are allocated with read access and added to nfs4_file's fi_fds[]. This is to allow the client to use the delegation stateid to do reads. No additional actions is needed when the delegation is returned. The nfsd_file for read remains attached to the nfs4_file and is freed when the open stateid is closed. The use of separate nfsd_file for read was suggested by Chuck. I also tried the suggestion by Jeff which is to "acquire a R/W open from the get-go instead when you intend to grant a delegation". To implement this approach, in nfs4_get_vfs_file OPEN4_SHARE_ACCESS_READ was added to op_share_access before computing the 'oflag' and 'access' flag. This forces the rest of the code to process the OPEN as if it was sent with access mode OPEN4_SHARE_ACCESS_WRITE|OPEN4_SHARE_ACCESS_READ. This mostly works except a case where the file was created with 0222 permission and the user credential of OPEN is not the same as the owner of the file. In this case the OPEN fails with NFS4ERR_ACCESS. This is because nfsd_permission was called with (MAY_READ | MAY_WRITE) mask and the file permission is 0222. I don't see any simple fix for this nfsd_permission issue. Basically the access mode has to be rdwr when creating the nfsd_file but the access mode passed to nfsd_permission to check should be rdonly (the original OPEN's op_share_access). v4: reacted to Jeff's comment v5: merged both patches into one to avoid potential bisect problem. fixed some nits from Jeff's comments v6: Fix deny_mode issue by not setting the read access in st_access_bmap when adding read access to write delegation. fs/nfsd/nfs4state.c | 75 ++++++++++++++++++++++++++++++------------------ 1 file changed, 47 insertions(+), 28 deletions(-)