Date: Sat, 02 Mar 2019 11:23:07 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: rmacklem@uoguelph.ca Cc: freebsd-rwg@pdx.rh.CN85.dnsmgr.net, freebsd-net@freebsd.org, bz@FreeBSD.org, rgrimes@freebsd.org Subject: Re: use of #ifdef INET and #ifdef INET6 in the kernel sources Message-ID: <20190302.112307.506661729975878277.hrs@allbsd.org> In-Reply-To: <QB1PR01MB35375F4B5EC31BBCEBF1C7CCDD770@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM> References: <201903011219.x21CJkIE061223@pdx.rh.CN85.dnsmgr.net> <QB1PR01MB35377AFB9049AF35F5A3037CDD760@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM> <QB1PR01MB35375F4B5EC31BBCEBF1C7CCDD770@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Sat_Mar__2_11_23_07_2019_942)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Macklem <rmacklem@uoguelph.ca> wrote in <QB1PR01MB35375F4B5EC31BBCEBF1C7CCDD770@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM>: rm> Rick Macklem wrote: rm> [stuff snipped] rm> >The AF_LOCAL code was in head for a short period of time before a vnode lock panic() rm> >issue was reported and I reverted the patch. rm> > rm> >Here is the commit log message for that reversion: rm> >PR#230752 shows a panic where an nfsd thread tries to do soconnect() on rm> >the AF_LOCAL socket used by the nfsuserd while already holding an rm> >exclusive lock on it. I am not 100% sure how this happens, but since an rm> >AF_LOCAL socket is in the file system namespace it is conceivable that it rm> >could lock it and then attempt an upcall to the nfsuserd. rm> >However, reverting r320757 stops the nfsuserd from using an AF_LOCAL rm> >socket, so it should avoid any such panic(). rm> >r320757 did fix a problem with running the nfsuserd when jails were rm> >enabled, but that can be dealt with less elegantly by allowing the rm> >use of an alternate address instead of 127.0.0.1. rm> >The gssd daemon also uses an AF_LOCAL socket, but it will do upcalls rm> >before the nfsd thread processes the RPC, so I think it should not rm> >be suseptible to this problem. rm> rm> Oops. Duh. I should have read my own commit message more carefully... rm> It was an nfsd thread, so the file system wasn't an NFS mount, it was a file rm> system exported to NFS client(s). rm> rm> It is possible to test to see if a file system is exported, but that can change rm> at any time, so even if it isn't exported when the nfsuserd daemon is started, rm> it could be exported later. rm> rm> So, I don't see any way AF_LOCAL can be safely used here. rm> rm> Oh, and the kernel RPC expects to be able to do a soconnect() using a rm> sockaddr, so socketpair() won't do the trick. Thank you for your clarification. I agree that AF_INET/AF_INET6 loopback address is much easier to avoid file system dependency. For the original question about whether we should use a hard-coded address or not, my suggestion is that we do not need to use the name "localhost" or rely on any Internet domain resolver code such as DNS as long as the hard-coded addresses cover all of supported address families (we have only two in practice). However, an option to specify a loopback address to be used might mitigate multiple loopback address issues in classical jail w/o VNET or multiple supported address families. Is there any problem with using NFSSVC_NFSUSERDPORT to pass a struct sockaddr (i.e. udptransp->xp_ltaddr, not only xp_port) directly? I think checking on kernel side if (sa_family == AF_INET or AF_INET6) and the address is already bound before the newfs_connect() call in nfsrv_nfsuserdport() guarantee that the specified sockaddr is a loopback address. Anyway, we might want to have AF_LOCAL socket with namespace which does not depend on any file system to communicate between kernel and userland. Linux has it for a long time (by putting '\0' at the head of an AF_LOCAL address) while I am still not sure if this is the best way to implement. While a new protocol family (PF_KEY is used in IPsec for example) also works for this purpose, it is probably a sledgehammer to crack a nut. -- Hiroki ----Security_Multipart(Sat_Mar__2_11_23_07_2019_942)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iEYEABECAAYFAlx56QsACgkQTyzT2CeTzy1fowCdH+oucHSs2UMFur6QXg7bTOpU Hy8AnRRGvQLsZtoyVzXM+Hw2BovZkNwB =ZuZC -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Mar__2_11_23_07_2019_942)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190302.112307.506661729975878277.hrs>