From nobody Thu Nov 30 19:03:17 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 4Sh5F36RxVz52R8y; Thu, 30 Nov 2023 19:03:19 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sh5F34M6hz3HJd; Thu, 30 Nov 2023 19:03:19 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 3AUJ3IhB046892; Thu, 30 Nov 2023 13:03:18 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1701370998; bh=hQAIT0ka1xicdyWj8jx7I4JhLTQRVlNmc8Dch1EEttQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=e7A8P2eEwebwAzWcvU5NYveVFkh6yT7I0Mb5vwzXSRizNe4jKWNPNZBuebE/ZpzLp n5vgGPN2Kng2VqpX8UOGVv0f1HippX269viSQ419Yn0drrvVJwBv6qsiY5UcPMeYQm Mb/0+gLlcyC7MljGvb8Ml5MK635vh2HbHM6SH1K9xj88fvwcAib4Ui8qAciqohdNgd ySeoV/OCNiHrAbQnZEroNi/wovXcHuz8JqHhx46Zf8aE+5BAG2suZS4hRZ8NRQ6MPw uuGcx1OSnhKop/yJ6h0rpUwq6o907HYZfwBOKRDnxhIraad4+/XWgb10GudKqrCspp wG0i2TX5Ytekg== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id 6K4YIXbcaGUqtwAAs/W3XQ (envelope-from ); Thu, 30 Nov 2023 13:03:18 -0600 From: Mike Karels To: Gleb Smirnoff 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) Date: Thu, 30 Nov 2023 13:03:17 -0600 X-Mailer: MailMate (1.14r5964) Message-ID: <46D00D21-64D9-4265-9055-29FDE87F6961@karels.net> In-Reply-To: References: <202311301634.3AUGYljD055413@gitrepo.freebsd.org> 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 Content-Transfer-Encoding: quoted-printable 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:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Queue-Id: 4Sh5F34M6hz3HJd 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 > M> > AuthorDate: 2023-11-30 16:30:55 +0000 > M> > Commit: Gleb Smirnoff > 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