Added asomers@ in case he'd like ot review this.

Seems ok to me.
There have already been commits that changed this
output format and no one has reported problems
because of that.
As such, I don't think this format change will
cause people problems.

This patch has been committed as r365703. It didn't get automatically
closed for some reason.

Fix a bug where the sig_mask being used as the
argument to sigsuspend() was set to the wrong
bits, where SIGHUP was blocked.

Updated with changes as suggested by kib@ and freqlabs@.

Use the variant of sig_intr() in D26628.

Well, when I looked at a wireshark trace of copying a 1Gbyte file,
it turns out that it is the Commit RPC (the one that does VOP_FSYNC())
that takes the time and not the Copy RPC, so using time on the
Copy RPC is useless.

Updated the inline comments.

Made the changes suggested by asomers@

Change the blksize test to handle the special case
where _PC_MIN_HOLE_SIZE is returned as 1.
As well as asomers@ suggested change, I also
changed the blksize code just below it.

Use rounddown() as suggested by asomers@.

Fixed the calculation to take *inoffp into account,
as suggested by asomers@.

Add a check for len being clipped down to 0.
No sense in doing the VOP call for this case.

Change handling of a wrap around of *outoffp + len
to clip "len" instead of return EINVAL.

Although there is no explicit statement in the NFS
RFCs indicating an upper limit on an RPC response
time, the assumption is that the server will reply
in a "reasonable time".
--> I think 1second is a reasonable time limit,

although some might argue it should be less
than that.

--> In NFSv4.2, a client can optionally specify the

  Copy operation be done "asynchronously",
  where the server replies to the Copy RPC when
  it is started and then does a server->client
  callback to notify completion.
  I have not implemented that, since I believe
  that the Linux server only does this for Copies
  between servers, which FreeBSD does not
  know how to do.
  Without the "asynchronous" option
, the Copy time needs to be limited
  to ensure a "timely" RPC reply.

The problem with using the "check for signals" approach
is that it won't work for the NFS server.
--> The NFS server will still need the 1sec timeout.
The VOP call can probably get away with using a
kernel only "flags" bit to indicate whether it should
use "1sec" vs "signal pending", but I'm not sure
if such semantics is overkill (the overhead of doing
1 syscall/sec isn't particularly high for a copy
like this.
Do others think this extra complexity is worth it?

Ok, so I have no idea how to do that.
Any suggestions?

Looks fine to me, but I've never had anything to do
with this code.
I think trasz@ was the author of the nfsv4 acl code,
so you might want to ask him?

Added a STANDARDS section, as suggested by gbe@.

Added some replies to inline comments.

Looks fine to me.

Interesting. SetClientID arguments are roughly:
A) - an identifier string (that should never change for a given client)
B) - a verifier that should change whenever the client looses state information

(usually a reboot)

C) - a host IP address for the server to use to do a connection to the

client for callbacks

Well, you are correct, in that other callers may
need similar fixes. (ie. Should never be called if
the ClientID is unconfirmed.)
--> For NFSv4.0, the only two are CBRECALL, to

 recall a delegation. This occurs when a
 conflicting open occurs and the check in
 nfsrv_checkopen() should be sufficient.
CBNULL, which is done during confirmation
to check for a callback path. (Again handled
by the current code, since it is done after the
LCL_NEEDSCONFIRM flag is cleared with the
global exclusive lock held.

--> There are Layout related CBs in NFSv4.1, but

since those use an established connection
with a session, I think they are ok, but I will
take a look.

Modify the entry to be NFS specific and add a comment
w.r.t. where it is handled, per inline comment.

Although it is not really NFS specific, NFS is probably the
only use case that will happen in my lifetime, so define
it as NFS specific and comment w.r.t. where it is handled.

Change the daemon's name from rpctlscd to rpc.tlsclntd
to avoid confusion with the server side daemon.

Rename rpctlssd to rpc.tlsservd, since that seemed to
be the preferred name for the daemon and this
hopefully will avoid confusion with the one for
the client side.

Remove "the" and "daemon" as suggested by bjk@
for the exports.5 patch.

Replied to inline comment and asked if rpc.tlssd would be preferable
to rpctlssd?

Take "the" and "daemon" out as suggested by bjk@.