Re: prison_flag() check in hot path of in_pcblookup()

On Tue, Dec 13, 2022 at 11:54:17PM +0000, Bjoern A. Zeeb wrote:
> On Tue, 13 Dec 2022, Andrew Gallatin wrote:
> 
> > [ I added pjd, since the original patch came from him ]
> >
> > Just to make sure I understand, I have a simple yes/no question:
> >
> > Can  jails and the host ever share the same (local) port and the same IP?
> 
> Can they currently (I tested only for TCP)?
> 
> - local binds can overlap like they can with just the base system.
>    so bind(... {AF_INET, laddr, lport} ... ) works fine (REUSEPORT).
> 
> - tcp connect of a 2nd socket to the same {faddr, fport} from the above
>    bind will fail with 'Address already in use'  [currently]
>    [I believe that would mean your patch could go in? Where does the error come from [%]?] [*]

I presume that the patch just causes the first loop in
in_pcblookup_hash_locked() to return immediately upon an exact match?  I
think this is only valid if in_pcblookup_hash_locked() can assume that
faddr != INADDR_ANY.  I'm pretty sure this is true but it's not entirely
obvious to me.

> - tcp listen will work on {laddr, lport} if run in paralllel (REUSEPORT)
>    or in base and jail at the same time.

I wonder if we can improve wildcard matching by enforcing an invariant
that jailed sockets always appear first in a hash chain?  That would
make hash insertion more expensive but that might be a reasonable
tradeoff.

> [%] likely in_pcbconnect_setup() ?  Also one should check the other
>      order (jail first then base);  also we assume no other race
>      conditions in this rather simple testing...