| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
the other 'struct pmap'.
Pointed out by: kmacy
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
|
| |
from returning a reply message in most cases. This in turn caused
interoperability problems with Mac OS X clients.
PR: 126561
Submitted by: Richard.Conto at gmail.com
MFC after: 1 week
|
| |
|
|
|
|
|
|
|
|
|
| |
mounts, Linux won't even bother registering nlockmgr for UDP. This
causes nlm_get_rpc to fail, which means any attempts to deliver the
GRANTED callback fail. Add code to nlm_get_rpc to try to locate the
TCP version as well. If it finds it on TCP, it establishes
a clnt_reconnect to the host.
Submitted by: zachary.loafman at isilon.com
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
|
|
|
|
| |
to global hostname and domainname variables. Where necessary, copy
to or from a stack-local buffer before performing copyin() or
copyout(). A few uses, such as in cd9660 and daemon_saver, remain
under-synchronized and will require further updates.
Correct a bug in which a failed copyin() of domainname would leave
domainname potentially corrupted.
MFC after: 3 weeks
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
provides the correct semantics for flock(2) style locks which are used by the
lockf(1) command line tool and the pidfile(3) library. It also implements
recovery from server restarts and ensures that dirty cache blocks are written
to the server before obtaining locks (allowing multiple clients to use file
locking to safely share data).
Sponsored by: Isilon Systems
PR: 94256
MFC after: 2 weeks
|
| |
|
|
|
|
| |
exists in my perforce branch :(
Pointy hat: dfr
|
| |
|
|
|
|
|
|
|
|
| |
a client reboot, do this check before performing the lock otherwise we
will trash the new lock along with any other old locks the client held
before rebooting.
Make sure nlm_check_idle always returns with nlm_global_lock held.
MFC after: 1 week
|
| |
|
|
|
|
|
|
| |
clients that have rebooted (or otherwise changed port numbers). If the
client is broken or has no active locks, it won't notify us. Fall back
on the two minute timeout logic used by the userland rpc.lockd code.
MFC after: 1 week
|
| |
|
|
| |
couple of spelling mistakes in comments.
|
| |
|
|
|
| |
Reported by: kris
MFC after: 3 days
|
| |
|
|
| |
without the INET6 option.
|
| | |
|
| |
|
|
|
|
|
| |
to detect (or load) kernel NLM support in rpc.lockd. Remove the '-k'
option to rpc.lockd and make kernel NLM the default. A user can still
force the use of the old user NLM by building a kernel without NFSLOCKD
and/or removing the nfslockd.ko module.
|
|
|
user-mode lock manager, build a kernel with the NFSLOCKD option and
add '-k' to 'rpc_lockd_flags' in rc.conf.
Highlights include:
* Thread-safe kernel RPC client - many threads can use the same RPC
client handle safely with replies being de-multiplexed at the socket
upcall (typically driven directly by the NIC interrupt) and handed
off to whichever thread matches the reply. For UDP sockets, many RPC
clients can share the same socket. This allows the use of a single
privileged UDP port number to talk to an arbitrary number of remote
hosts.
* Single-threaded kernel RPC server. Adding support for multi-threaded
server would be relatively straightforward and would follow
approximately the Solaris KPI. A single thread should be sufficient
for the NLM since it should rarely block in normal operation.
* Kernel mode NLM server supporting cancel requests and granted
callbacks. I've tested the NLM server reasonably extensively - it
passes both my own tests and the NFS Connectathon locking tests
running on Solaris, Mac OS X and Ubuntu Linux.
* Userland NLM client supported. While the NLM server doesn't have
support for the local NFS client's locking needs, it does have to
field async replies and granted callbacks from remote NLMs that the
local client has contacted. We relay these replies to the userland
rpc.lockd over a local domain RPC socket.
* Robust deadlock detection for the local lock manager. In particular
it will detect deadlocks caused by a lock request that covers more
than one blocking request. As required by the NLM protocol, all
deadlock detection happens synchronously - a user is guaranteed that
if a lock request isn't rejected immediately, the lock will
eventually be granted. The old system allowed for a 'deferred
deadlock' condition where a blocked lock request could wake up and
find that some other deadlock-causing lock owner had beaten them to
the lock.
* Since both local and remote locks are managed by the same kernel
locking code, local and remote processes can safely use file locks
for mutual exclusion. Local processes have no fairness advantage
compared to remote processes when contending to lock a region that
has just been unlocked - the local lock manager enforces a strict
first-come first-served model for both local and remote lockers.
Sponsored by: Isilon Systems
PR: 95247 107555 115524 116679
MFC after: 2 weeks
|
