Re: [PATCH v4] Make bindresvport() function to multithread-safe

[Rich Felker <dalias at aerifal dot cx>]

On Thu, Oct 25, 2012 at 02:25:46PM -0400, Carlos O'Donell wrote:
> On Thu, Oct 25, 2012 at 12:31 PM, Roland McGrath <roland@hack.frob.com> wrote:
> > I think it is indeed obvious without "collecting data" that bindresvport is
> > both not used widely, and not used frequently in programs that use it.  Its
> > purpose is something that only certain network programs would do, and that
> > they would do only at startup (or perhaps connection startup).
> 
> Is this statement based on your experience as a developer?
> 
> Honestly, I just don't have enough experience to evaluate the usage
> of bindresvport. Though I'm willing to accept such experience from Rich
> and yourself.

My claim is based on the fact that it's not a standardized function,
so unconditional usage of it will not appear in any portable program
that runs on systems other than glibc-based Linux. Also, the usage
cases for it are limited to programs that run as root and bind ports
that need to be in the reserved range to identify their authority to
other machines on the network -- a very small class of programs to
begin with, and a very dubious security mechanism.

> > A local lock satisfies the purposes and does not impose any cost on the
> > vast majority of programs that do not use the function.  Another solution
> > like using TLS that has collateral cost is only ever warranted once it's
> > positively demonstrated that the locking approach is too costly in practice.
> 
> Just to be clear the "collatoral cost" is only the initial relocation processing
> and the .tdata size added to each thread?

If it's initialized, the cost is 2 extra bytes (possibly 4 with
alignment) to memcpy on each thread's TLS init. If it's uninitialized,
the cost may only be increased TLS segment size, not copying, but I
believe glibc/NPTL reuses dirty memory for a new thread's TLS, so it
might have to memset the .tbss part to zero too.

Rich