Date: Thu, 30 Nov 2023 11:34:54 -0800 From: Gleb Smirnoff <glebius@freebsd.org> To: Mike Karels <mike@karels.net> 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: <ZWjj3jkNFmkf69MI@FreeBSD.org> In-Reply-To: <46D00D21-64D9-4265-9055-29FDE87F6961@karels.net> References: <202311301634.3AUGYljD055413@gitrepo.freebsd.org> <EB9A71A9-D44C-4DD8-92E8-A6506B51B7B1@karels.net> <ZWi_zsq9IWiJ_WTq@FreeBSD.org> <46D00D21-64D9-4265-9055-29FDE87F6961@karels.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZWjj3jkNFmkf69MI>