From nobody Thu Nov 30 19:34:54 2023 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sh5xY1bdjz52SRp; Thu, 30 Nov 2023 19:34:57 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from glebi.us (glebi.us [162.251.186.162]) by mx1.freebsd.org (Postfix) with ESMTP id 4Sh5xX6ZgKz3KWH; Thu, 30 Nov 2023 19:34:56 +0000 (UTC) (envelope-from glebius@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: by glebi.us (Postfix, from userid 1000) id EA436752CE; Thu, 30 Nov 2023 11:34:54 -0800 (PST) Date: Thu, 30 Nov 2023 11:34:54 -0800 From: Gleb Smirnoff To: Mike Karels 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: References: <202311301634.3AUGYljD055413@gitrepo.freebsd.org> <46D00D21-64D9-4265-9055-29FDE87F6961@karels.net> List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D00D21-64D9-4265-9055-29FDE87F6961@karels.net> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US] X-Rspamd-Queue-Id: 4Sh5xX6ZgKz3KWH 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