use of #ifdef INET and #ifdef INET6 in the kernel sources
Rick Macklem
rmacklem at uoguelph.ca
Sat Mar 2 00:58:14 UTC 2019
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
More information about the freebsd-net
mailing list