Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Nov 2023 13:03:17 -0600
From:      Mike Karels <mike@karels.net>
To:        Gleb Smirnoff <glebius@freebsd.org>
Cc:        src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org
Subject:   Re: git: cfb1e92912b4 - main - sockets: don't malloc/free  sockaddr memory on accept(2)
Message-ID:  <46D00D21-64D9-4265-9055-29FDE87F6961@karels.net>
In-Reply-To: <ZWi_zsq9IWiJ_WTq@FreeBSD.org>
References:  <202311301634.3AUGYljD055413@gitrepo.freebsd.org> <EB9A71A9-D44C-4DD8-92E8-A6506B51B7B1@karels.net> <ZWi_zsq9IWiJ_WTq@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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=3Dcfb1e92912b4cf75360=
b7fbe86197cc29bc212c1
> 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 so=
ckaddr_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 =3D 106
> (kgdb) p sizeof(struct sockaddr_storage)
> $2 =3D 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 woul=
d
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46D00D21-64D9-4265-9055-29FDE87F6961>