Re: Question about in_pcbbind() and in6_pcbbind()

Hi,
There are three issues that I'm wondering about regarding the two
functions mentioned in the subject:
1. When called from netinet/tcp_usrreq.c:tcp_usrrreq(), in_pcbbind()
takes "l", but in6_pcbbind() takes NULL:
[...]

We now pass always pass the lwp.

2. When called from the same locations, you'll also notice the second
argument (mbuf *nam) is NULL. Passing NULL is functionally equivalent
to passing a zeroed struct sockaddr_in6 wrapped in an mbuf, with one
difference: there's no sockaddr struct to pass to kauth(9). (We could
just pass the address and the port, but I think we'll be wasting
parameter space that way.)
[...]

I decided to slice in6_pcbbind(), and attached is the result (for
netinet6 only). It:
- Keeps in6_pcbbind()'s semantics,
- Introduces in6_pcbbind_{addr,port}()
- Uses "dom_sa_any" when the passed argument is NULL
(we could probably use some KASSERT()s in the two new functions to make
sure we don't end up *there* with sin6 == NULL, etc.)

3. It seems that in_pcbbind(), when exhausting all free ports when
auto-assigning a port, does the following:
[...]

This is fixed in the attached patch as well.
I've looked at both the FreeBSD and OpenBSD equivalents and it seems
that FreeBSD does address this issue by resetting the address "any",

but it does it in in6_pcbsetport(), which is also called from
udp6_output(), and I'm not sure resetting the laddr on the in6pcb is

intended (or desired?) in such a context -- so I reset the address if
in6_pcbsetport() fails in in6_pcbbind() itself.
Please review. :)
Thanks,
-e.