From nobody Sun Sep 7 00:26:49 2025 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 4cK9rP6xJkz65rsw; Sun, 07 Sep 2025 00:27:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cK9rP0Xfmz3Td6; Sun, 07 Sep 2025 00:27:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5870Qn4C061474; Sun, 7 Sep 2025 03:26:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5870Qn4C061474 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5870Qn2E061473; Sun, 7 Sep 2025 03:26:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 7 Sep 2025 03:26:49 +0300 From: Konstantin Belousov To: James Gritton Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 851dc7f859c2 - main - jail: add jail descriptors Message-ID: References: <202509042031.584KVpxY000408@gitrepo.freebsd.org> <2f66c886ab44aea5ad2e57cc72c03e3f@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: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2f66c886ab44aea5ad2e57cc72c03e3f@freebsd.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: / X-Spamd-Result: default: False [-0.99 / 15.00]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; NEURAL_HAM_SHORT(-0.56)[-0.562]; NEURAL_SPAM_LONG(0.56)[0.559]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; ARC_NA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; HAS_XAW(0.00)[]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org,dev-commits-src-main@freebsd.org]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[4] X-Rspamd-Queue-Id: 4cK9rP0Xfmz3Td6 On Fri, Sep 05, 2025 at 10:57:30AM -0700, James Gritton wrote: > On 2025-09-04 22:14, Konstantin Belousov wrote: > > BTW, you added some support for kqueue for jail events, but not to the > > jail file descriptors. This seems to be backward: if somebody wants to > > monitor events for jails, then it is more reliable and straightforward > > to do with the new jail fds rather than with ids. > > It is at least incomplete, and not the state I want things to be at. > There's a sticking point with jaildesc kqueue, so while I work that > out I went with jid-baseds kqueue as a starter. > > The trouble is child jails. I took their handling from the existing > child process handling, where I register a new kevent under the new > jail's id. But that's something I can't do with descriptors, since > they have a process-specific identifier, the descriptor number. The > code that creates the new event, coming from the jail_set call that > created a new jail, has access to the global descriptor (the struct > file), but not to the process(es) that have it open, so I have no > way of registering one or more events with that descriptor number. > > One workaround is to have both jid- and jaildesc-based kevents, but > both of them register a new jid-based kevent for a newly created child > jail. The caller may then get a descriptor with jail_get, and add a > kevent for it and remove the old jid-based one. This would work, but > feels really klunky. > > The other idea I've had is to register a temporary event, and then add > code to kqueue_scan that converts that into a proper jaildesc event > with the expected file descriptor number. That would require either > jaildesc-specific code in or around kqueue_scan, or adding another > filterops function, neither of which is great. Still, it seems the > better solution. This is not how the monitoring APIs work in general. For instance, when you register a listening socket in kqueue (or mark it for select or poll), you do not get back a new connected file descriptor. Kqueue only provides a notification that new connection arrived, and then code needs to accept it and get the file descriptor for new connection using dedicated socket API. > > With working jaildesc kevent support, the jid-based kevents would be > unnecessary, so if I can get this done before 15 is released, they can > go away. > Then what is the point in adding something that app writers can't rely upon, since this something is going away soon? IMO, this whole commit series is not ready and the most lacking part is the discussion of the architecture of the feature.