summaryrefslogtreecommitdiffstats
path: root/sys/fs/nfsclient/nfs_clstate.c
Commit message (Collapse)AuthorAgeFilesLines
* MFC: r317465rmacklem2017-05-101-1/+10
| | | | | | | | | | 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.
* MFC: r317345rmacklem2017-05-081-8/+20
| | | | | | | | | | | | | 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.
* MFC: r317305rmacklem2017-05-081-19/+33
| | | | | | | | | | | 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.
* MFC: r316829rmacklem2017-04-291-2/+1
| | | | | | | | | 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.
* MFC: r316792rmacklem2017-04-271-13/+63
| | | | | | | | | | | | 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
* MFC: r316719rmacklem2017-04-261-9/+3
| | | | | | | | | | | 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.
* MFC: r316717rmacklem2017-04-261-9/+8
| | | | | | | | | | | | | 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.
* MFC: r316669rmacklem2017-04-251-1/+11
| | | | | | | | | 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.
* MFC: r310491rmacklem2017-04-241-30/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* MFC: r304026rmacklem2016-10-031-29/+29
| | | | | | | | | | | | 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.
* NFS: spelling fixes on comments.pfg2016-04-291-1/+1
| | | | No funcional change.
* Cleanup unnecessary semicolons from the kernel.pfg2016-04-101-2/+2
| | | | Found with devel/coccinelle.
* Merge the NFSv4.1 server code in projects/nfsv4.1-server overrmacklem2014-07-011-1/+1
| | | | | | | | | 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. MFC after: 1 month
* There might be a potential race condition for the NFSv4 clientrmacklem2014-06-281-17/+17
| | | | | | | | | | | 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. MFC after: 2 weeks
* The NFSv4 client was passing both the p and cred arguments tormacklem2013-12-241-1/+1
| | | | | | | | | 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. MFC after: 1 week
* The NFSv4.1 client didn't return NFSv4.1 specific error codesrmacklem2013-12-231-6/+11
| | | | | | | | 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. MFC after: 1 week
* Fix r252074 so that it builds on 64bit arches.rmacklem2013-06-221-3/+1
|
* The NFSv4.1 LayoutCommit operation requires a valid offset and length.rmacklem2013-06-211-8/+20
| | | | | (0, 0 is not sufficient) This patch a loop for each file layout, using the offset, length of each file layout in a separate LayoutCommit.
* The request queue is already locked, so we don't need the splsofclock/splximp2013-02-211-3/+1
| | | | here to note future work.
* Further cleanups to use of timestamps in NFS:jhb2013-01-251-5/+5
| | | | | | | | | | | | | | | - Use NFSD_MONOSEC (which maps to time_uptime) instead of the seconds portion of wall-time stamps to manage timeouts on events. - Remove unused nd_starttime from the per-request structure in the new NFS server. - Use nanotime() for the modification time on a delegation to get as precise a time as possible. - Use time_second instead of extracting the second from a call to getmicrotime(). Submitted by: bde (3) Reviewed by: bde, rmacklem MFC after: 2 weeks
* Move the NFSv4.1 client patches over from projects/nfsv4.1-clientrmacklem2012-12-081-96/+1072
| | | | | | | | | | to head. I don't think the NFS client behaviour will change unless the new "minorversion=1" mount option is used. It includes basic NFSv4.1 support plus support for pNFS using the Files Layout only. All problems detecting during an NFSv4.1 Bakeathon testing event in June 2012 have been resolved in this code and it has been tested against the NFSv4.1 server available to me. Although not reviewed, I believe that kib@ has looked at it.
* r228827 fixed a problem where copying of NFSv4 open credentials intormacklem2012-02-071-2/+6
| | | | | | | | | | | | | | | | a credential structure would corrupt it. This happened when the p argument was != NULL. However, I now realize that the copying of open credentials should only happen for p == NULL, since that indicates that it is a read-ahead or write-behind. This patch fixes this. After this commit, r228827 could be reverted, but I think the code is clearer and safer with the patch, so I am going to leave it in. Without this patch, it was possible that a NFSv4 VOP_SETATTR() could have changed the credentials of the caller. This would have happened if the process doing the VOP_SETATTR() did not have the file open, but some other process running as a different uid had the file open for writing at the same time. MFC after: 5 days
* Post r223774, the NFSv4 client no longer has multiple instancesrmacklem2011-12-031-52/+93
| | | | | | | | | | | | | | | | | of the same lock_owner4 string. As such, the handling of cleanup of lock_owners could be simplified. This simplification permitted the client to do a ReleaseLockOwner operation when the process that the lock_owner4 string represents, has exited. This permits the server to release any storage related to the lock_owner4 string before the associated open is closed. Without this change, it is possible to exhaust a server's storage when a long running process opens a file and then many child processes do locking on the file, because the open doesn't get closed. A similar patch was applied to the Linux NFSv4 client recently so that it wouldn't exhaust a server's storage. Reviewed by: zack MFC after: 2 weeks
* Clean up some cruft in the NFSv4 client left over from thermacklem2011-11-211-13/+6
| | | | | | | OpenBSD port, so that it is more readable. No logic change is made by this commit. MFC after: 2 weeks
* Since the nfscl_cleanup() function isn't used by the FreeBSD NFSv4 client,rmacklem2011-11-201-33/+7
| | | | | | | delete the code and fix up the related comments. This should not have any functional effect on the client. MFC after: 2 weeks
* Post r223774 the NFSv4 client never uses the linked list with thermacklem2011-11-201-58/+0
| | | | | | | | | head nfsc_defunctlockowner. This patch simply removes the code that loops through this always empty list, since the code no longer does anything useful. It should not have any effect on the client's behaviour. MFC after: 2 weeks
* r222389 introduced a case where the NFSv4 client couldrmacklem2011-07-131-1/+2
| | | | | | | | | | loop in nfscl_getcl() when a forced dismount is in progress, because nfsv4_lock() will return 0 without sleeping when MNTK_UNMOUNTF is set. This patch fixes it so it won't loop calling nfsv4_lock() for this case. MFC after: 2 weeks
* The algorithm used by nfscl_getopen() could have resulted inrmacklem2011-07-041-81/+94
| | | | | | | | | | | | | | | | multiple instances of the same lock_owner when a process both inherited an open file descriptor plus opened the same file itself. Since some NFSv4 servers cannot handle multiple instances of the same lock_owner string, this patch changes the algorithm used by nfscl_getopen() in the new NFSv4 client to keep that from happening. The new algorithm is simpler, since there is no longer any need to ascend the process's parentage tree because all NFSv4 Closes for a file are done at VOP_INACTIVE()/VOP_RECLAIM(), making the Opens indistinct w.r.t. use with Lock Ops. This problem was discovered at the recent NFSv4 interoperability Bakeathon. MFC after: 2 weeks
* Modify the new NFSv4 client so that it appends a file handlermacklem2011-07-031-2/+1
| | | | | | | | | | | | | to the lock_owner4 string that goes on the wire. Also, add code to do a ReleaseLockOwner Op on the lock_owner4 string before a Close. Apparently not all NFSv4 servers handle multiple instances of the same lock_owner4 string, at least not in a compatible way. This patch avoids having multiple instances, except for one unusual case, which will be fixed by a future commit. Found at the recent NFSv4 interoperability Bakeathon. Tested by: tdh at excfb.com MFC after: 2 weeks
* The new NFSv4 client was erroneously using "p" instead ofrmacklem2011-06-051-15/+17
| | | | | | | | | | "p_leader" for the "id" for POSIX byte range locking. I think this would only have affected processes created by rfork(2) with the RFTHREAD flag specified. This patch fixes that by passing the "id" down through the various functions from nfs_advlock(). MFC after: 2 weeks
* Fix the new NFS client so that it handles NFSv4 statermacklem2011-05-271-16/+78
| | | | | | | | | | | | | | | | | correctly during a forced dismount. This required that the exclusive and shared (refcnt) sleep lock functions check for MNTK_UMOUNTF before sleeping, so that they won't block while nfscl_umount() is getting rid of the state. As such, a "struct mount *" argument was added to the locking functions. I believe the only remaining case where a forced dismount can get hung in the kernel is when a thread is already attempting to do a TCP connect to a dead server when the krpc client structure called nr_client is NULL. This will only happen just after a "mount -u" with options that force a new TCP connection is done, so it shouldn't be a problem in practice. MFC after: 2 weeks
* Revert r220761 since, as kib@ pointed out, the case ofrmacklem2011-04-181-4/+0
| | | | | | | | adding the check to nfsrpc_close() isn't useful. Also, the check in nfscl_getcl() must be more involved, since it needs to check before and after the acquisition of the refcnt on nfsc_lock, while the mutex that protects the client state data is held.
* Add checks for MNTK_UNMOUNTF at the beginning of threermacklem2011-04-171-0/+4
| | | | | | | | | | | | | | | | | | | functions, so that threads don't get stuck in them during a forced dismount. nfs_sync/VFS_SYNC() needs this, since it is called by dounmount() before VFS_UNMOUNT(). The nfscl_nget() case makes sure that a thread doing an VOP_OPEN() or VOP_ADVLOCK() call doesn't get blocked before attempting the RPC. Attempting RPCs don't block, since they all fail once a forced dismount is in progress. The third one at the beginning of nfsrpc_close() is done so threads don't get blocked while doing VOP_INACTIVE() as the vnodes are cleared out. With these three changes plus a change to the umount(1) command so that it doesn't do "sync()" for the forced case seem to make forced dismounts work for the experimental NFS client. MFC after: 2 weeks
* Fix the experimental NFSv4 server so that it uses VOP_PATHCONF()rmacklem2011-04-141-1/+1
| | | | | | | | | to determine if a file system supports NFSv4 ACLs. Since VOP_PATHCONF() must be called with a locked vnode, the function is called before nfsvno_fillattr() and the result is passed in as an extra argument. MFC after: 2 weeks
* Modify the experimental NFSv4 server so that it handlesrmacklem2011-04-141-2/+3
| | | | | | | | | | | | | crossing of server mount points properly. The functions nfsvno_fillattr() and nfsv4_fillattr() were modified to take the extra arguments that are the mount point, a flag to indicate that it is a file system root and the mounted on fileno. The mount point argument needs to be busy when nfsvno_fillattr() is called, since the vp argument is not locked. Reviewed by: kib MFC after: 2 weeks
* Add a flag to the experimental NFSv4 client to indicate whenrmacklem2010-10-261-22/+23
| | | | | | | | | | | | | delegations are being returned for reasons other than a Recall. Also, re-organize nfscl_recalldeleg() slightly, so that it leaves clearing NMODIFIED to the ncl_flush() call and invalidates the attribute cache after flushing. It is hoped that these changes might fix the problem others have seen when using the NFSv4 client with delegations enabled, since I can't reliably reproduce the problem. These changes only affect the client when doing NFSv4 mounts with delegations enabled. MFC after: 10 days
* Modify the return value for nfscl_mustflush() from boolean_t,rmacklem2010-08-031-5/+5
| | | | | | | | which I mistakenly thought was correct w.r.t. style(9), back to int and add the checks for != 0. This is just a stylistic modification. MFC after: 1 week
* Change the nfscl_mustflush() function in the experimental NFSv4rmacklem2010-07-181-5/+5
| | | | | | | client to return a boolean_t in order to make it more compatible with style(9). MFC after: 2 weeks
* An NFSv4 server will reply NFSERR_GRACE for non-recovery RPCsrmacklem2010-04-241-11/+13
| | | | | | | | | | | | during the grace period after startup. This grace period must be at least the lease duration, which is typically 1-2 minutes. It seems prudent for the experimental NFS client to wait a few seconds before retrying such an RPC, so that the server isn't flooded with non-recovery RPCs during recovery. This patch adds an argument to nfs_catnap() to implement a 5 second delay for this case. MFC after: 1 week
* When the experimental NFS client is handling an NFSv4 server rebootrmacklem2010-04-221-6/+19
| | | | | | | | | | | | with delegations enabled, the recovery could fail if the renew thread is trying to return a delegation, since it will not do the recovery. This patch fixes the above by having nfscl_recalldeleg() fail with the I/O operations returning EIO, so that they will be attempted later. Most of the patch consists of adding an argument to various functions to indicate the delegation recall case where this needs to be done. MFC after: 1 week
* For the experimental NFS client doing an NFSv4 mount,rmacklem2010-04-201-3/+6
| | | | | | | | | | set the NFSCLFLAGS_RECVRINPROG while doing recovery from an expired lease in a manner similar to r206818 for server reboot recovery. This will prevent the function that acquires stateids for I/O operations from acquiring out of date stateids during recovery. Also, fix up mutex locking on the nfsc_flags field. MFC after: 1 week
* Avoid extraneous recovery cycles in the experimental NFS clientrmacklem2010-04-181-4/+29
| | | | | | | | | | | | | | when an NFSv4 server reboots, by doing two things. 1 - Make the function that acquires a stateid for I/O operations block until recovery is complete, so that it doesn't acquire out of date stateids. 2 - Only allow a recovery once every 1/2 of a lease duration, since the NFSv4 server must provide a recovery grace period of at least a lease duration. This should avoid recoveries caused by an out of date stateid that was acquired for an I/O op. just before a recovery cycle started. MFC after: 1 week
* Add mutex lock calls to 2 cases in the experimental NFS client'srmacklem2010-04-151-2/+6
| | | | | | renew thread where they were missing. MFC after: 1 week
* The experimental NFS client was not filling in recovery credentialsrmacklem2010-04-151-2/+7
| | | | | | | | | | | for opens done locally in the client when a delegation for the file was held. This could cause the client to crash in crsetgroups() when recovering from a server crash/reboot. This patch fills in the recovery credentials for this case, in order to avoid the client crash. Also, add KASSERT()s to the credential copy functions, to catch any other cases where the credentials aren't filled in correctly. MFC after: 1 week
* Fix three related problems in the experimental nfs client whenrmacklem2010-01-031-24/+19
| | | | | | | checking for conflicts w.r.t. byte range locks for NFSv4. 1 - Return 0 instead of EACCES when a conflict is found, for F_GETLK. 2 - Check for "same file" when checking for a conflict. 3 - Don't check for a conflict for the F_UNLCK case.
* Fix comment typos.jh2009-10-201-4/+4
| | | | | Reviewed by: rmacklem Approved by: trasz (mentor)
* When using an NFSv4 mount in the experimental nfs client with delegationsrmacklem2009-07-221-1/+1
| | | | | | | | | | | being issued from the server, there was a case where an Open issued locally based on the delegation would be released before the associated vnode became inactive. If the delegation was recalled after the open was released, an Open against the server would not have been acquired and subsequent I/O operations would need to use the special stateid of all zeros. This patch fixes that case. Approved by: re (kensmith), kib (mentor)
* Since the nfscl_getclose() function both decremented open counts and,rmacklem2009-07-091-99/+96
| | | | | | | | | | | | | optionally, created a separate list of NFSv4 opens to be closed, it was possible for the associated OpenOwner to be free'd before the Open was closed. The problem was that the Open was taken off the OpenOwner list before the Close RPC was done and OpenOwners can be free'd once the list is empty. This patch separates out the case of doing the Close RPC into a separate function called nfscl_doclose() and simplifies nfsrpc_doclose() so that it closes a single open instead of a list of them. This avoids removing the Open from the OpenOwner list before doing the Close RPC. Approved by: re (kensmith), kib (mentor)
* Use getcredhostuuid instead of accessing the prison directly.jamie2009-06-131-5/+1
| | | | Approved by: bz (mentor)
* Fix nfscl_getcl() so that it doesn't crash when it is called tormacklem2009-06-081-20/+29
| | | | | | | do an NFSv4 Close operation with the cred argument NULL. Also, clarify what NULL arguments mean in the function's comment. Approved by: kib (mentor)
OpenPOWER on IntegriCloud