#
334635 |
|
04-Jun-2018 |
rmacklem |
MFC: r334252 Fix the sleep event for layout recall.
The sleep for I/O completion during an NFSv4.1 pNFS layout recall used the wrong event value and could result in the "[nfscl]" thread hung for the mount. This patch fixes the event to be the correct. This bug will only affect NFSv4.1 pnfs mounts and only when the server does a layout recall callback, so it won't affect many. Without the patch, a mount without the "pnfs" option will avoid the problem. Found during testing of the pNFS server.
|
#
324545 |
|
11-Oct-2017 |
rmacklem |
MFC: r324074 Fix a memory leak that occurred in the pNFS client.
When a "pnfs" NFSv4.1 mount was unmounted, it didn't free up the layouts and deviceinfo structures. This leak only affects "pnfs" mounts and only when the mount is umounted. Found while testing the pNFS Flexible File layout client code.
|
#
320795 |
|
07-Jul-2017 |
rmacklem |
MFC: r320208 Ensure that the credentials field of the NFSv4 client open structure is initialized.
bdrewery@ has reported panics "newnfs_copycred: negative nfsc_ngroups". The only way I can see that this occurs is that the credentials field of the open structure gets used before being filled in. I am not sure quite how this happens, but for the file create case, the code is serialized via the vnode lock on the directory. If, somehow, a link to the same file gets created just after file creation, this might occur.
This patch ensures that the credentials field is initialized to a reasonable set of credentials before the structure is linked into any list, so I this should ensure it is initialized before use. I am committing the patch now, since bdrewery@ notes that the panics are intermittent and it may be months before he knows if the patch fixes his problem.
|
#
318128 |
|
10-May-2017 |
rmacklem |
MFC: r317465 Fix handling of a NFSv4.1 callback reply from the session cache.
The nfsv4_seqsession() call returns NFSERR_REPLYFROMCACHE when it has a reply in the session, due to a requestor retry. The code erroneously assumed a return of 0 for this case. This patch fixes this and adds a KASSERT(). This would be an extremely rare occurrence. It was found during code inspection during the pNFS server development.
|
#
317984 |
|
08-May-2017 |
rmacklem |
MFC: r317345 Make the NFSv4 client to use a write open for reading if allowed by the server.
An NFSv4 server has the option of allowing a Read to be done using a Write Open. If this is not allowed, the server will return NFSERR_OPENMODE. This patch attempts the read with a write open and then disables this if the server replies NFSERR_OPENMODE. This change will avoid some uses of the special stateids. This will be useful for pNFS/DS Reads, since they cannot use special stateids. It will also be useful for any NFSv4 server that does not support reading via the special stateids. It has been tested against both types of NFSv4 server.
|
#
317978 |
|
08-May-2017 |
rmacklem |
MFC: r317305 Fix the NFSv4.1/pNFS client return layout on close.
The "return layout on close" case in the pNFS client was badly broken. Fortunately, extant pNFS servers that I have tested against do not do this. This patch fixes it. It also changes the way the layout stateid.seqid is set for LayoutReturn. I think this change is correct w.r.t. the RFC, but I am not 100% sure. This was found during recent testing of the pNFS server under development.
|
#
317579 |
|
29-Apr-2017 |
rmacklem |
MFC: r316829 Remove unused "cred" argument to ncl_flush().
The "cred" argument of ncl_flush() is unused and it was confusing to have the code passing in NULL for this argument in some cases. This patch deletes this argument. There is no semantic change because of this patch.
|
#
317525 |
|
27-Apr-2017 |
rmacklem |
MFC: r316792 Add an NFSv4.1 mount option for "use one openowner".
Some NFSv4.1 servers such as AmazonEFS can only support a small fixed number of open_owner4s. This patch adds a mount option called "oneopenown" that can be used for NFSv4.1 mounts to make the client do all Opens with the same open_owner4 string. This option can only be used with NFSv4.1 and may not work correctly when Delegations are is use.
Differential Revision: https://reviews.freebsd.org/D8988
|
#
317475 |
|
26-Apr-2017 |
rmacklem |
MFC: r316719 Don't throw away Open state when a NFSv4.1 client recovery fails.
If the ExchangeID/CreateSession operations done by an NFSv4.1 client after the server crashes/reboots fails, it is possible that some process/thread is waiting for an open_owner lock. If the client state is free'd, this can cause a crash. This would not normally happen, but has been observed on a mount of the AmazonEFS service.
|
#
317474 |
|
26-Apr-2017 |
rmacklem |
MFC: r316717 During a server crash recovery, fix the NFSv4.1 client for a NFSERR_BADSESSION during recovery.
If the NFSv4.1 client gets a NFSv4.1 NFSERR_BADSESSION reply to an Open/Lock operation while recovering from the server crash/reboot, allow the opens to be retained for a subsequent recovery attempt. Since NFSv4.1 servers should only reply NFSERR_BADSESSION after a crash/reboot that has lost state, this case should almost never happen. However, for the AmazonEFS file service, this has been observed when the client does a fresh TCP connection for RPCs.
|
#
317423 |
|
25-Apr-2017 |
rmacklem |
MFC: r316669 Avoid starvation of the server crash recovery thread for the NFSv4 client.
This patch gives a requestor of the exclusive lock on the client state in the NFSv4 client priority over shared lock requestors. This avoids the server crash recovery thread being starved out by other threads doing RPCs.
|
#
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.
|
#
268580 |
|
12-Jul-2014 |
rmacklem |
MFC: r268008 There might be a potential race condition for the NFSv4 client when a newly created file has another open done on it that update the open mode. This patch moves the code that updates the open mode up into the block where the mutex is held to ensure this cannot happen. No bug caused by this potential race has been observed, but this fix is a safety belt to ensure it cannot happen.
|
#
260143 |
|
31-Dec-2013 |
rmacklem |
MFC: r259801 The NFSv4 client was passing both the p and cred arguments to nfsv4_fillattr() as NULLs for the Getattr callback. This caused nfsv4_fillattr() to not fill in the Change attribute for the reply. I believe this was a violation of the RFC, but had little effect on server behaviour. This patch passes a non-NULL p argument to fix this.
|
#
260109 |
|
30-Dec-2013 |
rmacklem |
MFC: r259771 The NFSv4.1 client didn't return NFSv4.1 specific error codes for the Getattr and Recall callbacks. This patch fixes it. Since the NFSv4.1 specific error codes would only happen for abnormal circumstances, this patch has little effect, in practice.
|
#
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.
|
#
268580 |
|
12-Jul-2014 |
rmacklem |
MFC: r268008 There might be a potential race condition for the NFSv4 client when a newly created file has another open done on it that update the open mode. This patch moves the code that updates the open mode up into the block where the mutex is held to ensure this cannot happen. No bug caused by this potential race has been observed, but this fix is a safety belt to ensure it cannot happen.
|
#
260143 |
|
31-Dec-2013 |
rmacklem |
MFC: r259801 The NFSv4 client was passing both the p and cred arguments to nfsv4_fillattr() as NULLs for the Getattr callback. This caused nfsv4_fillattr() to not fill in the Change attribute for the reply. I believe this was a violation of the RFC, but had little effect on server behaviour. This patch passes a non-NULL p argument to fix this.
|
#
260109 |
|
30-Dec-2013 |
rmacklem |
MFC: r259771 The NFSv4.1 client didn't return NFSv4.1 specific error codes for the Getattr and Recall callbacks. This patch fixes it. Since the NFSv4.1 specific error codes would only happen for abnormal circumstances, this patch has little effect, in practice.
|