[NFS-Ganesha-Devel] Re: NFSv4 Read not allowed on file opened with OPEN4_SHARE_ACCESS_WRITE and got write delegation(OPEN_DELEGATE_WRITE)

Soumya, I got your point that open_state may not exist when the reads are done with deleg_state, so you need this block of code. So the check here should have been similar to the check done below as per RFC. But I did not understand the point of checking share_deny as well. When a client performs open with share_deny set to say read, it means other clients should be denied read but not itself right? So what is the point of checking my own 'sdeleg->share_deny' or even 'state_open->state_data.share.share_deny' as done in share lock check below.

That is the reason I said, we do not need any check of my own share_access or deleg_type checks while doing read, the conflicting lock and delegation checks will anyway be performed by open already. Regards, Deepthi On 05/02/20, 4:03 PM, "Soumya Koduri" <skoduri(a)redhat.com&gt; wrote: On 2/5/20 3:21 PM, des(a)vmware.com wrote: > According to page 112 in RFC 7530, NFSv4 read operation should be allowed on a open state with share access OPEN4_SHARE_ACCESS_WRITE to accommodate clients whose write implementation may unavoidably do reads (e.g., due to buffer cache constraints). > This condition is taken care in normal flow in nfs4_read() in here: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.... > RFC doesn't clearly state if the same applies even in case of delegations. So I am not sure about it though logically it may make sense to allow reads if its the same client. Nevertheless, we do need below block. In case there is delegation granted, READs are performed using delegation state and there is no open state and hence shall bypass share_access checks below. Maybe we can check for sdeleg->share_deny instead of sdeleg->share_access in this block to verify if ACCESS_READ is denied. Thanks, Soumya > But if the open has granted a write delegation(OPEN_DELEGATE_WRITE), then the check for deleg state in nfs4_read() does not allow Read op as per RFC mentioned above but return NFS4ERR_BAD_STATEID. > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.... > > case STATE_TYPE_DELEG: > /* Check if the delegation state allows READ or > * if the open share state allows READ access > * in case of WRITE delegation */ > sdeleg = &state_found->state_data.deleg; > if (!((sdeleg->sd_type & OPEN_DELEGATE_READ) || > (sdeleg->share_access & OPEN4_SHARE_ACCESS_READ))) { > /* Invalid delegation for this operation. */ > LogDebug(COMPONENT_STATE, > "Delegation type:%d state:%d", > sdeleg->sd_type, > sdeleg->sd_state); > res_READ4->status = NFS4ERR_BAD_STATEID; > goto out; > } > > state_open = NULL; > break; > > The ubuntu nfs client when it wants to write data, always opens file with OPEN4_SHARE_ACCESS_WRITE and not OPEN4_SHARE_ACCESS_BOTH like other linux clients, so with delegation enabled if we just do "echo data > file.txt ; cat file.txt", it hangs forever with read op getting NFS4ERR_BAD_STATEID and client retrying forever. > > I feel this whole block under 'case STATE_TYPE_DELEG' is not needed at all, as the share access check will anyway happen below and we need not check the delegation state while doing read operation. > _______________________________________________ > Devel mailing list -- devel(a)lists.nfs-ganesha.org > To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org >