Re: git: cfb1e92912b4 - main - sockets: don't malloc/free sockaddr memory on accept(2)

On Thu, Nov 30, 2023 at 01:03:17PM -0600, Mike Karels wrote:
M> > M> >     Let the accept functions provide stack memory for protocols to fill it in.
M> > M> >     Generic code should provide sockaddr_storage, specialized code may provide
M> > M> >     smaller structure.
M> > M>
M> > M> Does this mean that families cannot support sockaddrs bigger than sockaddr_storage?
M> > M> In particular, does local domain (aka unix domain)?  Did it before?
M> >
M> > Yes, but I assume sockaddr_storage should cover anything:
M> >
M> > (kgdb) p sizeof(struct sockaddr_un)
M> > $1 = 106
M> > (kgdb) p sizeof(struct sockaddr_storage)
M> > $2 = 128
M> >
M> > Please correct me if I'm wrong.
M> >
M> > -- 
M> > Gleb Smirnoff
M> 
M> Looks like local domain doesn't support anything larger than sockaddr_un; it
M> uses that structure for everything.  The original theory was that it would
M> actually be variable, but sockaddr_un was made to be the size of an mbuf
M> (less overhead) for convenience.  I don't know if the theory was ever
M> implemented.
M> 
M> I like the idea of having the lower level be able to control the length
M> of the address arbitrarily, rather than enforcing a global maximum.
M> But the sockaddr would have to be copied anyway, and it is nice to avoid
M> the malloc/free.  So I won't object to this change.
M> 
M> At this point, we could just as well increase the size of sockaddr_un to
M> agree with sockaddr_storage.  On the other hand, most uses seem to fill
M> and/or copy the whole sockaddr, so that would increase overhead slightly,
M> and historical usage obviously fits in the current size.

Exactly matches my evaluation. :) Looks like everybody is happy with existing
sockaddr_un.  Thanks for reviewing, Mike!

-- 
Gleb Smirnoff