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>