Updated patch renames pfind_locked() to pfind_any_locked(), per mjg@'s request.

pfind_locked() has been renamed pfind_any_locked() and a comment
indicating that it finds zombies has been added, per mjg@'s request.

Replied to inline comment.

I have included responses to the inline comments.

This version of the patch uses SX_DUPOK instead of a separate name for each
lock. It also adds a couple of small functions to kern_proc.c to acquire/release
all the pid hash locks, so that the NFS code can call those instead of doing it directly.

I just read the man page (I know, never read the documentation;-) and it seems that
the recursion check is for exclusive locks, so adding SX_DUPOK would allow a process
to acquire a shared lock that it already has.
So, maybe, sticking with the current patch that applies a unique name to each element
is preferred?

Ok, the inline comments were still there, so I have just responded to them.

This version of the patch brings in pfind_locked() from stable/12, but with the
sx_assert() changed.
Since the code the inline comments were applied to has been removed from this patch,
I'll try to address mjg@'s comments here:

• Yes, the "optimization" I left in the code wouldn't have ever happened. I just left it in the code so that it looked more like _pfind(). Since that code isn't in pfind_locked(), it is gone.
• The old pfind_locked() found zombie processes. I know that works ok and I'm not sure that the code would work correctly if zombie processes aren't found. Some of these open/lock_owners refer to opens, where a child of the zombie process might still have the file open. Delaying the cleanup of it until the children die only delays the garbage collection, so all that happens is a little malloc()d memory doesn't get released as soon. Since freeing the openowner prematurely would break things badly, I'd rather leave it finding zombie processes. (The code should delay the cleanup until all opens are closed, but...)

Marked rgrimes@ inline comments as done, per his instructions.

This version of the patch has the changes mentioned in the inline comments.
A comment has been added explaining that INET[6]_ADDRSTRLEN includes
NULL termination and the length calculation has been changed to "-1 + 8"
from "+ 7" to make the calculation more understandable.

Added replies to the inline comments. I will update the patch with the changes mentioned
in the replies later to-day.
Thanks for the review, rick

Fixed one place where I had typed AF_INET when it should have been AF_INET6.
This didn't seem to have caused problems during testing, so I don't think it actually mattered,
but it is now correct.

Marked rgrimes inline comments done per his request.

Replied to the inline comments.

Oops, I think I uploaded the wrong version of the diff. Here is
the correct one with updated kernel changes that include #ifdef INET and INET6.

This version of the patch has an updated set of kernel changes
against head that include the #ifdef INET and INET6.

Looks ok, rick

Looks ok, rick

Looks ok, rick

Looks ok, rick

Looks ok, rick

Looks ok, rick

Looks ok, rick

Looks ok, rick

Looks ok, rick

Looks ok, rick

Looks ok, rick

Looks ok, rick

Looks ok, rick

Looks ok, rick

Loos ok, rick

Looks ok, rick

Look ok to me.

Looks ok. I'm not sure I understand why having a lot of "struct thread *p = curthread;"s in
the local variables of the functions is an improvement over passing it as an argument,
but I see no harm in it?

Looks ok to me.

Looks ok to me.

My concern is that all sorts of signals get posted to processes and you don't want any old
signal to interrupt an attempt at an upcall. The failure of a gssd should be a rare occurrence
and so long as the upcall doesn't try "forever", I think that will be sufficient.

Yes, sometime in April I will revert the AF_LOCAL patch from head and then create an updated (simpler)
kernel patch, including the #ifdef INET/INET6.

This patch has the .include <src.opts.mk> added to the Makefile and has the kernel
patch, which I was going to leave until later, but bz@ wanted to compile the code,
so here it is.
(Note that the kernel patch mostly replaces the AF_LOCAL socket code that is unused,
because the patch to nfsuserd.c for this was reverted and never MFC'd. As such, the kernel
changes won't apply to a stable branch and is only for head. I am planning on first reverting
the kernel change for AF_LOCAL and then applying the changes, so the patch that will be
committed to head for the kernel changes won't look the same as this patch, although the
post-commit code should look the same.)

Updated the patch with changes suggested by bz@. I did not change the usage
of INET6_LOOOPBACK_INIT, since I couldn't see an easy way to use it to initialize
a "struct sockaddr_storage". (There might be a C trick to using this initializer
that I don't know about.

Oops, my mistake. I didn't notice he had made multiple comments.
I see it now and will add the ifdefs.

Whether or not "#ifdef INET6" and "#ifdef INET" should be in the code is still an open question.
I was hoping bz@ could answer this?
(I, personally, was of the understanding that this was no longer required/recommended for
FreeBSD sources. If bz@ does not know the correct answer for this, I will ask on freebsd-net@.)
At this point I have made no changes to the Makefile.
To build/run it, there is a small kernel change required, but I did not include that in this review.

This version of the patch includes the changes that bz@ recommended.
I think he meant sockaddr_storage when he said sockaddr_union, so I
made "fromip" one of those instead of having both "fromip" and "fromip6"
plus "use_inet6" to decide which to use.
It uses INET6 if it can and uses the INADDR_LOOPBACK and IN6ADDR_LOOPBACK_INIT
macros.

W.r.t. the NFS root mount, you are sort of correct at this time.
What would happen for an NFSv4 root mount at this time is
that the NFS client code would have a miss on the "uid<->username"
cache and attempt an upcall to the nfsuserd, which would not
work. (I think it will eventually fail and use "nobody", but I'd have
to look at the code to be sure.
As such, NFSv4 root mounts are not currently recommended, but I
would like to resolve that someday.

Added a comment w.r.t. why "localhost" is hardcoded. I will also note that the kernel will
use these hardcoped values (I don't believe the kernel can do a name lookup and I wouldn't
want it to in this case), so the code doesn't want to use any other value, if a sysadmin were
to change the values for "localhost".

The problem with doing a name lookup in this daemon is that it assumes/expects it
to work. Often (an NFS mounted root fs is one example and a system configured to
use DNS before the local /etc/hosts file) are not yet working and an NFS mount is
expected to work.
(ie. In general I'd agree with you, but for NFS not so much...)

Looks fine to me now. Thanks, rick

Thanks for adding the strlen() check. I am going to be nitpicky and suggest an
error message be printed (not sure if the nfsd should fail or just log an error?),
since silently ignoring the "-V" argument could cause confusion too, I think?

Looks ok to me. (I'll admit I don't understand when it is useful, but that's ok.;-)
The one change I might suggest is a sanity check for the strlen() of the "-V" optarg
being <= MAXHOSTNAMELEN.

This one looks fine to me, rick.

First off, I should note that I am not the author of this code. If dfr@ could review this, that could be better.

Looks fine to me, although I'll admit I've never noticed there was a CLIENT_MAX in this code.
(I wasn't the author.)