#
338308 |
|
24-Aug-2018 |
rmacklem |
MFC: r337438 Allow newnfs_request() to retry all callback RPCs with an NFSERR_DELAY reply.
The code in newnfs_request() retries RPCs that get a reply of NFSERR_DELAY, but exempts certain NFSv4 operations. However, for callback RPCs, there should not be any exemptions at this time. The code would have erroneously exempted the CBRECALL callback, since it has the same operation number as the CLOSE operation. This patch fixes this by checking for a callback RPC (indicated by clp != NULL) and not checking for exempt operations for callbacks. This would have only affected the NFSv4 server when delegations are enabled (they are not enabled by default) and the client replies to CBRECALL with NFSERR_DELAY. This may never actually happen. Spotted during code inspection.
|
#
336899 |
|
30-Jul-2018 |
rmacklem |
MFC: r334966 Add a couple of safety belt checks to the NFSv4.1 client related to sessions.
There were a couple of cases in newnfs_request() that it assumed that it was an NFSv4.1 mount with a session. This should always be the case when a Sequence operation is in the reply or the server replies NFSERR_BADSESSION. However, if a server was broken and sent an erroneous reply, these safety belt checks should avoid trouble. The one check required a small tweak to nfsmnt_mdssession() so that it returns NULL when there is no session instead of the offset of the field in the structure (0x8 for i386). This patch should have no effect on normal operation of the client. Found by inspection during pNFS server development.
|
#
325407 |
|
04-Nov-2017 |
rmacklem |
MFC: r324506 Fix forced dismount when a pNFS mount is hung on a DS.
When a "pnfs" NFSv4.1 mount is hung because of an unresponsive DS, a forced dismount wouldn't work, because the RPC socket for the DS was not being closed. This patch fixes this. This will only affect "pnfs" mounts where the pNFS server's DS is unresponsive (crashed or network partitioned or...). Found during testing of the pNFS server.
|
#
320637 |
|
04-Jul-2017 |
rmacklem |
MFC: r320062, r320070, r320126 This is a partial merge of only the NFS changes and not the maxbcachebuf tunable.
The NFS client changes make the code handle different I/O sizes more correctly. However, with the limit at 64K, they are not actually necessary. This MFC is mainly being done so that subsequent MFCs to the NFS code will merge easily.
|
#
317930 |
|
07-May-2017 |
rmacklem |
MFC: r317276 Don't set ND_NOMOREDATA for a failed Setattr operation (NFSv4).
The NFSv4 Setattr operation always has reply data even when it fails, so don't set the ND_NOMOREDATA for it. This would only affect unusual cases where Setattr fails and the RPC code wants to parse the rest of the compound. Detected during recent development related to the pNFS server.
|
#
317927 |
|
07-May-2017 |
rmacklem |
MFC: r317275, r317344 Don't create a backchannel for a DS connection.
An NFSv4.1 client connection to a Data Server (DS) should not have a backchannel. This patch fixes the NFSv4.1/pNFS client to not do a backchannel for this case. Found during recent testing with the pNFS server under development.
|
#
317404 |
|
25-Apr-2017 |
rmacklem |
MFC: r310491 Fix NFSv4.1 client recovery from NFS4ERR_BAD_SESSION errors.
For most NFSv4.1 servers, a NFS4ERR_BAD_SESSION error is a rare failure that indicates that the server has lost session/open/lock state. However, recent testing by cperciva@ against the AmazonEFS server found several problems with client recovery from this due to it generating this failure frequently. Briefly, the problems fixed are: - If all session slots were in use at the time of the failure, some processes would continue to loop waiting for a slot on the old session forever. - If an RPC that doesn't use open/lock state failed with NFS4ERR_BAD_SESSION, it would fail the RPC/syscall instead of initiating recovery and then looping to retry the RPC. - If a successful reply to an RPC for an old session wasn't processed until after a new session was created for a NFS4ERR_BAD_SESSION error, it would erroneously update the new session and corrupt it. - The use of the first element of the session list in the nfs mount structure (which is always the current metadata session) was slightly racey. With changes for the above problems it became more racey, so all uses of this head pointer was wrapped with a NFSLOCKMNT()/NFSUNLOCKMNT(). - Although the kernel malloc() usually allocates more bytes than requested and, as such, this wouldn't have caused problems, the allocation of a session structure was 1 byte smaller than it should have been. (Null termination byte for the string not included in byte count.)
There are probably still problems with a pNFS data server that fails with NFS4ERR_BAD_SESSION, but I have no server that does this to test against (the AmazonEFS server doesn't do pNFS), so I can't fix these yet.
Although this patch is fairly large, it should only affect the handling of NFS4ERR_BAD_SESSION error replies from an NFSv4.1 server. Thanks go to cperciva@ for the extension testing he did to help isolate/fix these problems.
|
#
306663 |
|
03-Oct-2016 |
rmacklem |
Revert r306659 since the userland changes won't merge and this would break the build.
|
#
306659 |
|
03-Oct-2016 |
rmacklem |
MFC: r304026 Update the nfsstats structure to include the changes needed by the patch in D1626 plus changes so that it includes counts for NFSv4.1 (and the draft of NFSv4.2). Also, make all the counts uint64_t and add a vers field at the beginning, so that future revisions can easily be implemented. There is code in place to handle the old vesion of the nfsstats structure for backwards binary compatibility.
Subsequent commits will update nfsstat(8) to use the new fields.
|
#
269398 |
|
01-Aug-2014 |
rmacklem |
MFC: r268115 Merge the NFSv4.1 server code in projects/nfsv4.1-server over into head. The code is not believed to have any effect on the semantics of non-NFSv4.1 server behaviour. It is a rather large merge, but I am hoping that there will not be any regressions for the NFS server.
|
#
259207 |
|
10-Dec-2013 |
rmacklem |
MFC: r257598 During code inspection, I spotted that there was a code path where CLNT_CONTROL() would be called on "client" after it was released via CLNT_RELEASE(). It was unlikely that this code path gets executed and I have not heard of any problem report caused by this bug. This patch fixes the code so that this cannot happen.
|
#
269398 |
|
01-Aug-2014 |
rmacklem |
MFC: r268115 Merge the NFSv4.1 server code in projects/nfsv4.1-server over into head. The code is not believed to have any effect on the semantics of non-NFSv4.1 server behaviour. It is a rather large merge, but I am hoping that there will not be any regressions for the NFS server.
|
#
259207 |
|
10-Dec-2013 |
rmacklem |
MFC: r257598 During code inspection, I spotted that there was a code path where CLNT_CONTROL() would be called on "client" after it was released via CLNT_RELEASE(). It was unlikely that this code path gets executed and I have not heard of any problem report caused by this bug. This patch fixes the code so that this cannot happen.
|