On 5/22/25 11:51 AM, Petro Pavlov wrote: > Hello, > > My name is Petro Pavlov, I'm a developer at VAST. > > I have a few questions about the delegation claim behavior observed in > the Linux kernel version 3.10.0-1160.118.1.el7.x86_64. > > I’ve written the following test case: > > 1. Client1 opens *file1* with a write delegation; the server grants > both the open and delegation (*delegation1*). Since you mention a write delegation, I'll assume you are using Linux as an NFS client, and the server is not Linux, since that kernel version does not implement server-side write delegation. > 2. Client1 closes the open but does not return the delegation. > 3. Client2 opens *file2* and also receives a write delegation > (*delegation2*). > 4. Client1 then issues an open request with CLAIM_DELEGATE_CUR, > providing the filename from step 3 *(file2*), but using the > delegation stateid from step 1 (*delegation1*). Would that be a client bug? > 5. The server begins a recall of *delegation2*, treating the request in > step 4 as a normal open rather than returning a BAD_STATEID error. That seems OK to me. The server has correctly noticed that the client is opening file2, and delegation2 is associated with a previous open of file2. A better place to seek an authoritative answer might be RFC 8881. The server returns BAD_STATEID if the stateid doesn't pass various checks as outlined in Section 8.2. I don't see any text requiring the server to report BAD_STATEID if delegate_stateid does not match the component4 on a DELEGATE_CUR OPEN -- in fact, Table 19 says that DELEGATE_CUR considers only the current file handle (the parent directory) and the component4 argument. > My understanding is that the server should have verified whether the > delegation stateid provided actually belongs to the file being opened. > Since it does not, I expected the server to return a BAD_STATEID error > instead of proceeding with a standard open. > > From additional tests, it seems the server only checks whether the > delegation stateid is valid (i.e., whether it was ever granted), but > does not verify that it is associated with the correct file or client. > Please see the attached PCAP for reference. > > Questions: > > Is this behavior considered a bug? > > Are there any known plans to address or fix this issue in future kernel > versions? AFAICT at the moment, NOTABUG -- Chuck Lever
