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

On 30 Nov 2023, at 11:01, Gleb Smirnoff wrote:

> On Thu, Nov 30, 2023 at 10:56:23AM -0600, Mike Karels wrote:
> M> On 30 Nov 2023, at 10:34, Gleb Smirnoff wrote:
> M>
> M> > The branch main has been updated by glebius:
> M> >
> M> > URL: https://cgit.FreeBSD.org/src/commit/?id=cfb1e92912b4cf75360b7fbe86197cc29bc212c1
> M> >
> M> > commit cfb1e92912b4cf75360b7fbe86197cc29bc212c1
> M> > Author:     Gleb Smirnoff <glebius@FreeBSD.org>
> M> > AuthorDate: 2023-11-30 16:30:55 +0000
> M> > Commit:     Gleb Smirnoff <glebius@FreeBSD.org>
> M> > CommitDate: 2023-11-30 16:30:55 +0000
> M> >
> M> >     sockets: don't malloc/free sockaddr memory on accept(2)
> M> >
> M> >     Let the accept functions provide stack memory for protocols to fill it in.
> M> >     Generic code should provide sockaddr_storage, specialized code may provide
> M> >     smaller structure.
> M>
> M> Does this mean that families cannot support sockaddrs bigger than sockaddr_storage?
> M> In particular, does local domain (aka unix domain)?  Did it before?
>
> Yes, but I assume sockaddr_storage should cover anything:
>
> (kgdb) p sizeof(struct sockaddr_un)
> $1 = 106
> (kgdb) p sizeof(struct sockaddr_storage)
> $2 = 128
>
> Please correct me if I'm wrong.
>
> -- 
> Gleb Smirnoff

Looks like local domain doesn't support anything larger than sockaddr_un; it
uses that structure for everything.  The original theory was that it would
actually be variable, but sockaddr_un was made to be the size of an mbuf
(less overhead) for convenience.  I don't know if the theory was ever
implemented.

I like the idea of having the lower level be able to control the length
of the address arbitrarily, rather than enforcing a global maximum.
But the sockaddr would have to be copied anyway, and it is nice to avoid
the malloc/free.  So I won't object to this change.

At this point, we could just as well increase the size of sockaddr_un to
agree with sockaddr_storage.  On the other hand, most uses seem to fill
and/or copy the whole sockaddr, so that would increase overhead slightly,
and historical usage obviously fits in the current size.

		Mike