use of #ifdef INET and #ifdef INET6 in the kernel sources

[Rick Macklem]

Rick Macklem wrote:
[stuff snipped]
>The AF_LOCAL code was in head for a short period of time before a vnode lock panic()
>issue was reported and I reverted the patch.
>
>Here is the commit log message for that reversion:
>PR#230752 shows a panic where an nfsd thread tries to do soconnect() on
>the AF_LOCAL socket used by the nfsuserd while already holding an
>exclusive lock on it. I am not 100% sure how this happens, but since an
>AF_LOCAL socket is in the file system namespace it is conceivable that it
>could lock it and then attempt an upcall to the nfsuserd.
>However, reverting r320757 stops the nfsuserd from using an AF_LOCAL
>socket, so it should avoid any such panic().
>r320757 did fix a problem with running the nfsuserd when jails were
>enabled, but that can be dealt with less elegantly by allowing the
>use of an alternate address instead of 127.0.0.1.
>The gssd daemon also uses an AF_LOCAL socket, but it will do upcalls
>before the nfsd thread processes the RPC, so I think it should not
>be suseptible to this problem.

Oops. Duh. I should have read my own commit message more carefully...
It was an nfsd thread, so the file system wasn't an NFS mount, it was a file
system exported to NFS client(s).

It is possible to test to see if a file system is exported, but that can change
at any time, so even if it isn't exported when the nfsuserd daemon is started,
it could be exported later.

So, I don't see any way AF_LOCAL can be safely used here.

Oh, and the kernel RPC expects to be able to do a soconnect() using a
sockaddr, so socketpair() won't do the trick.

rick