Date: Sat, 2 Mar 2019 00:58:10 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> Cc: FreeBSD Net <freebsd-net@freebsd.org>, "hrs@freebsd.org" <hrs@FreeBSD.org>, "Bjoern A. Zeeb" <bz@FreeBSD.org>, "rgrimes@freebsd.org" <rgrimes@freebsd.org> Subject: Re: use of #ifdef INET and #ifdef INET6 in the kernel sources Message-ID: <QB1PR01MB35375F4B5EC31BBCEBF1C7CCDD770@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <QB1PR01MB35377AFB9049AF35F5A3037CDD760@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM> References: <QB1PR01MB3537DB5BF5EE01C6006B3090DD760@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM>, <201903011219.x21CJkIE061223@pdx.rh.CN85.dnsmgr.net>, <QB1PR01MB35377AFB9049AF35F5A3037CDD760@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
Rick Macklem wrote: [stuff snipped] >The AF_LOCAL code was in head for a short period of time before a vnode lo= ck 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 fil= e system exported to NFS client(s). It is possible to test to see if a file system is exported, but that can ch= ange at any time, so even if it isn't exported when the nfsuserd daemon is start= ed, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QB1PR01MB35375F4B5EC31BBCEBF1C7CCDD770>