Date: Fri, 1 Mar 2019 23:35:13 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> Cc: "Bjoern A. Zeeb" <bz@FreeBSD.org>, FreeBSD Net <freebsd-net@freebsd.org>, "rgrimes@freebsd.org" <rgrimes@freebsd.org>, "hrs@freebsd.org" <hrs@freebsd.org> Subject: Re: use of #ifdef INET and #ifdef INET6 in the kernel sources Message-ID: <QB1PR01MB35377AFB9049AF35F5A3037CDD760@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <201903011219.x21CJkIE061223@pdx.rh.CN85.dnsmgr.net> References: <QB1PR01MB3537DB5BF5EE01C6006B3090DD760@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM>, <201903011219.x21CJkIE061223@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Rodney W. Grimes wrote: >Rick Macklem wrote: >> I doubt NFS gets squeezed into such devices and, yes, it is a small amou= nt. >> Using source line counts via "wc" (ir includes comments, etc): >> - This will reduce the # of lines by about 6 for a module of about 7700 = lines >> which is loaded when either the nfscl or nfsserver modules are loaded= . >> (These are both about 25000 lines and require the krpc, which is anot= her 10000. >> I haven't included the Kerberos stuff, because I can't remember if = that gets loaded >> unless Kerberos mounts get used.) >> --> A savings of 6 lines in something like 43000. > >That means that nfsusrd is an extremly well behaved ipv4/ipv6 >agnostic deamon that only takes a small change to make it able >to run as either v4/v6 as a single stack or dual stacked, at a cost >that also sounds minial, even if it took an #ifdef for each of these >lines that is only 6 in 43000 lines of code, which is a small cost. Just fyi, the above referred to the kernel changes and not nfsuserd.c, but = it doesn't really matter. I accept the argument that it documents where INET and INET6 code is . >The same analysis on other code probably comes out no place near >this. > >Also didnt this use to use a unix domain? Could the unix domain >be put back and knobbed so that I could actually run this without >it doing the localnet thing at all? I know that it had issues >as the socket is in /tmp and if /tmp isnt a right type file system, >etc... But some of us do know that and do run with a /tmp that >would support AF_UNIX type nfsusrd. > >If it takes 6 lines of ifdef to do v4 vs v6, how many lines of >ifdef is it to add AF_UNIX back and make it run time choice? > >(Goes looking for more Nomex clothing :-) The AF_LOCAL code was in head for a short period of time before a vnode loc= k 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. As you can see from the above, I wasn't 100% sure what caused the vnode loc= k panic(). It might only occur for the AF_LOCAL socket being on an NFS mount, but I am= not sure. I also don't like the idea of code that depends on the kind of underlying f= ile system to function correctly. (The VFS/VOP interface is meant to make "type of file s= ystem" transparent to userland as far as possible, as I see it.) So, I don't feel comfortable with enabling AF_LOCAL for certain file system= types, since I know using an INET/INET6 socket address avoids the problem. I could make an argument for some other "namespace" for local sockets other= than the file system directory structure, but that sounds like way too much work= for me... rick ps: I think the above answers hrs@'s comment about AF_LOCAL as well.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QB1PR01MB35377AFB9049AF35F5A3037CDD760>