#
259065 |
|
07-Dec-2013 |
gjb |
- Copy stable/10 (r259064) to releng/10.0 as part of the 10.0-RELEASE cycle. - Update __FreeBSD_version [1] - Set branch name to -RC1
[1] 10.0-CURRENT __FreeBSD_version value ended at '55', so start releng/10.0 at '100' so the branch is started with a value ending in zero.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
252100 |
|
22-Jun-2013 |
rmacklem |
Fix r252074 so that it builds on 64bit arches.
|
#
252074 |
|
21-Jun-2013 |
rmacklem |
The NFSv4.1 LayoutCommit operation requires a valid offset and length. (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.
|
#
247072 |
|
21-Feb-2013 |
imp |
The request queue is already locked, so we don't need the splsofclock/splx here to note future work.
|
#
245909 |
|
25-Jan-2013 |
jhb |
Further cleanups to use of timestamps in NFS: - 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
|
#
244042 |
|
08-Dec-2012 |
rmacklem |
Move the NFSv4.1 client patches over from projects/nfsv4.1-client 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.
|
#
231133 |
|
07-Feb-2012 |
rmacklem |
r228827 fixed a problem where copying of NFSv4 open credentials into 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
|
#
228217 |
|
03-Dec-2011 |
rmacklem |
Post r223774, the NFSv4 client no longer has multiple instances 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
|
#
227796 |
|
21-Nov-2011 |
rmacklem |
Clean up some cruft in the NFSv4 client left over from the OpenBSD port, so that it is more readable. No logic change is made by this commit.
MFC after: 2 weeks
|
#
227744 |
|
19-Nov-2011 |
rmacklem |
Since the nfscl_cleanup() function isn't used by the FreeBSD NFSv4 client, delete the code and fix up the related comments. This should not have any functional effect on the client.
MFC after: 2 weeks
|
#
227743 |
|
19-Nov-2011 |
rmacklem |
Post r223774 the NFSv4 client never uses the linked list with the 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
|
#
223971 |
|
12-Jul-2011 |
rmacklem |
r222389 introduced a case where the NFSv4 client could 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
|
#
223774 |
|
04-Jul-2011 |
rmacklem |
The algorithm used by nfscl_getopen() could have resulted in 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
|
#
223747 |
|
03-Jul-2011 |
rmacklem |
Modify the new NFSv4 client so that it appends a file handle 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
|
#
222719 |
|
05-Jun-2011 |
rmacklem |
The new NFSv4 client was erroneously using "p" instead of "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
|
#
222389 |
|
27-May-2011 |
rmacklem |
Fix the new NFS client so that it handles NFSv4 state 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
|
#
220807 |
|
18-Apr-2011 |
rmacklem |
Revert r220761 since, as kib@ pointed out, the case of 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.
|
#
220761 |
|
17-Apr-2011 |
rmacklem |
Add checks for MNTK_UNMOUNTF at the beginning of three 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
|
#
220648 |
|
14-Apr-2011 |
rmacklem |
Fix the experimental NFSv4 server so that it uses VOP_PATHCONF() 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
|
#
220645 |
|
14-Apr-2011 |
rmacklem |
Modify the experimental NFSv4 server so that it handles 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
|
#
214406 |
|
26-Oct-2010 |
rmacklem |
Add a flag to the experimental NFSv4 client to indicate when 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
|
#
210786 |
|
02-Aug-2010 |
rmacklem |
Modify the return value for nfscl_mustflush() from boolean_t, 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
|
#
210201 |
|
17-Jul-2010 |
rmacklem |
Change the nfscl_mustflush() function in the experimental NFSv4 client to return a boolean_t in order to make it more compatible with style(9).
MFC after: 2 weeks
|
#
207170 |
|
24-Apr-2010 |
rmacklem |
An NFSv4 server will reply NFSERR_GRACE for non-recovery RPCs 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
|
#
207082 |
|
22-Apr-2010 |
rmacklem |
When the experimental NFS client is handling an NFSv4 server reboot 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
|
#
206880 |
|
19-Apr-2010 |
rmacklem |
For the experimental NFS client doing an NFSv4 mount, 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
|
#
206818 |
|
18-Apr-2010 |
rmacklem |
Avoid extraneous recovery cycles in the experimental NFS client 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
|
#
206690 |
|
15-Apr-2010 |
rmacklem |
Add mutex lock calls to 2 cases in the experimental NFS client's renew thread where they were missing.
MFC after: 1 week
|
#
206688 |
|
15-Apr-2010 |
rmacklem |
The experimental NFS client was not filling in recovery credentials 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
|
#
201439 |
|
03-Jan-2010 |
rmacklem |
Fix three related problems in the experimental nfs client when 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.
|
#
198289 |
|
20-Oct-2009 |
jh |
Fix comment typos.
Reviewed by: rmacklem Approved by: trasz (mentor)
|
#
195819 |
|
22-Jul-2009 |
rmacklem |
When using an NFSv4 mount in the experimental nfs client with delegations 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)
|
#
195510 |
|
09-Jul-2009 |
rmacklem |
Since the nfscl_getclose() function both decremented open counts and, 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)
|
#
194117 |
|
13-Jun-2009 |
jamie |
Use getcredhostuuid instead of accessing the prison directly.
Approved by: bz (mentor)
|
#
193735 |
|
08-Jun-2009 |
rmacklem |
Fix nfscl_getcl() so that it doesn't crash when it is called to 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)
|
#
193066 |
|
29-May-2009 |
jamie |
Place hostnames and similar information fully under the prison system. The system hostname is now stored in prison0, and the global variable "hostname" has been removed, as has the hostname_mtx mutex. Jails may have their own host information, or they may inherit it from the parent/system. The proper way to read the hostname is via getcredhostname(), which will copy either the hostname associated with the passed cred, or the system hostname if you pass NULL. The system hostname can still be accessed directly (and without locking) at prison0.pr_host, but that should be avoided where possible.
The "similar information" referred to is domainname, hostid, and hostuuid, which have also become prison parameters and had their associated global variables removed.
Approved by: bz (mentor)
|
#
192337 |
|
18-May-2009 |
rmacklem |
Change the experimental NFSv4 client so that it does not do the NFSv4 Close operations until ncl_inactive(). This is necessary so that the Open StateIDs are available for doing I/O on mmap'd files after VOP_CLOSE(). I also changed some indentation for the nfscl_getclose() function.
Approved by: kib (mentor)
|
#
191783 |
|
04-May-2009 |
rmacklem |
Add the experimental nfs subtree to the kernel, that includes support for NFSv4 as well as NFSv2 and 3. It lives in 3 subdirs under sys/fs: nfs - functions that are common to the client and server nfsclient - a mutation of sys/nfsclient that call generic functions to do RPCs and handle state. As such, it retains the buffer cache handling characteristics and vnode semantics that are found in sys/nfsclient, for the most part. nfsserver - the server. It includes a DRC designed specifically for NFSv4, that is used instead of the generic DRC in sys/rpc. The build glue will be checked in later, so at this point, it consists of 3 new subdirs that should not affect kernel building.
Approved by: kib (mentor)
|