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 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[email protected]"
