Re: mountd, rpc.lockd and rpc.statd patches for testing

On Thu, Apr 19, 2012 at 08:44:37PM -0400, Rick Macklem wrote:
> Andrey Simonenko wrote:
> > On Mon, May 30, 2011 at 04:56:02PM -0400, Rick Macklem wrote:
> > > Hi,
> > >
> > > I have patches for the mountd, rpc.statd and rpc.lockd daemons
> > > that are meant to keep them from failing when a dynamically
> > > selected port# is not available for some combination of
> > >   udp,tcp X ipv4,ipv6
> > >
> > > If anyone would like to test these patches, they can be found
> > > at:
> > >    http://people.freebsd.org/~rmacklem/mountd.patch
> > >                                        statd.patch
> > >                                        lockd.patch
> > >
> > > Although I think I got them correct, they are rather big and ugly.
> > >
> > 
> > I have checked this update for mountd in 10-CURRENT and has two
> > questions:
> > 
> > 1. What is the sense to try to use the same port number for all
> > supported netconfigs if specific port number is not given in
> > a command line option?
> > 
> Well, there was a discussion of this on one of the mailing lists
> at the time. I started with a much simpler patch that didn't try and
> make all 4 <udp/tcp, ip4/ip6> combinations use the same port#, but
> others felt that was important. (Something about tracking what port#
> were in use, but I can't quite recall. If you want to know the reasoning,
> look for the thread that would have been shortly before the commit.)
> 

I verified how mountd, rpc.lockd and rpc.statd worked on previous
version of FreeBSD.  On 6.2-PRERELEASE mountd, rpc.lockd and rpc.statd
did not have the -h option and all these programs used random port numbers
for all netconfigs.  When the -h option was added to mountd, rpc.lockd
and rpc.statd this logic was changed and random port was used for all
netconfigs and for all IP address if they are specified.  Obviously
everyone who used NFS after these changes got non working NFS several
times even for configurations without the -h option.

rpcbind(8) in FreeBSD does not allow multiple settings for the same
network ID, so wildcard address for each netconfig should be used.
As I understand this is a design decision and multiple settings for
one RPC service are refused in rpcbind/rpcb_svc_com.c:map_set().

Would all possible cases be checked before commiting support for
the -h option, may be that option and broken logic will not appear
in mountd, rpc.lockd and rpc.statd.  Now, everything "works", but mountd
still can fail during startup (depends on activity of other network
programs of course).

> > 
> > One comment for netconfig related functions usage. Each setnetconfig()
> > call allocates memory and depending on implementation can use other
> > resources, so endnetconfig() should be called before reusing netconfig
> > handle.
> > _
> Ok, I'll take a look someday. Since it happens a finite number of times,
> any leak should be bounded and, as such, shouldn't cause serious problems.
> However, I wasn't aware of the above and it should be fixed.
> 

When I worked on my changes for NFS server, I verified implementation of
netconfig related function in RPC part of libc and not closed netconfig
handles results in memory leaks and one opened file descriptor for netconfig
database.  BTW there are several mistakes in that part of code, so I wrote
correct implementation in kern/165710 ("kern" category was autoassigned).