Re: git: cfb1e92912b4 - main - sockets: don't malloc/free sockaddr memory on accept(2)
Date: Thu, 30 Nov 2023 19:34:54 UTC
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