From nobody Sun Sep 7 16:25:59 2025 X-Original-To: dev-commits-src-all@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 4cKb6w2fjSz66RP8; Sun, 07 Sep 2025 16:26:00 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cKb6w13QBz3lST; Sun, 07 Sep 2025 16:26:00 +0000 (UTC) (envelope-from jamie@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757262360; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nQKGO/YuU4deXnJ3zifEAJx/DwrBQ9uXih+tZjr6wFA=; b=cslTM3YPCh2TJoS45M/fhxD/UAOtS9TWuxzt4/hlnOq+2Cvj50eWaeKa4G5mscj8DGi1hn V5U8LTMrsjYcoOgVrS4PqjQuxh9qEnLmD++amo8IfTkRVsWQ8grCvSgBKfGkYt9+JeXWAf e38hS+3APCaz6YbRpGP/qUdtS3VqXhoCoP8Q2hEJoJNmfK8GBjex1nsis6UwU4jUN9Sm69 7eNtjwLlu8ceZbvtAsrbBcGZMvRZCzGCgZYYN0PWnkzqUB/s4cQ8uwj0MTHKRWvqmG3AR5 hzZctFscwdhEC0Fiuw9lfa1/fPNOe/8xOUHLwb2YTGlUyxiZ7q+v+ZbkYAdT9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757262360; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nQKGO/YuU4deXnJ3zifEAJx/DwrBQ9uXih+tZjr6wFA=; b=XYQgUE8pTBy+JB6MEXbwd6kbOspHY4X4PdfOzwfvDCe9UUcpbYo209X7Zsr8rK5q9xf55l 5DMCMG/XLTlGTfq2Jjmbx+94SrOuCcxr9KGzt3e6dhyG/a8KYACgzwfiUSPOOIkWM8LfK7 c+vvefZiGX0UoGRM3ui085B4nwWXREQwbxKwHBrRu8BqNXguIqHLDV3Fq1au9pyePfm/tW a7HKzoucDtYHZ5nwm+lglv77jfrOfdOW0JZoh4iDjPiaeCVdAQDiHfUjk0ODlxSYieiIXv KuZjHA/M1Luh0UfX73eh1TSWIV7rCB2R3Gl157kmDjuiLjun+eOcBu7e/9HIow== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1757262360; a=rsa-sha256; cv=none; b=JWZdYP2KQvbNhODLr+mrzZyKMSwBl6tr1mkhxSsSQ+lNuEl2sbYbwRMzS1zP+ABR9jbgiK M+jP+f95o53ua6gMDG15HuQUmuAWQNStwFPTbGQH0R587wyIZ9cl+1hY4SXeA7edAgYQ76 5M2t7JOu7/uS7SvxyC11GlpwM85z05WpABejH6DGQ5xBnbdL6B/dVf15ZfM6Rf6aZliQT1 1a7wKhkzVTbKPK25q92dQdXo6SmGmTrjCw+r7hKYismnSDaXFHBp3enEW92122fB0ZA+Y8 RViUAL5zNgOG7vg+tyP+PUgSLIXs3eMyk92IeIzQi3yRjTkOZetqg2PmcMga1A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from m2.gritton.org (gritton.org [67.43.236.212]) (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) (Authenticated sender: jamie) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cKb6w06Dfz17gt; Sun, 07 Sep 2025 16:25:59 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (localgritton [127.0.0.212]) by m2.gritton.org (Postfix) with ESMTPSA id 7454179B7D; Sun, 7 Sep 2025 09:25:59 -0700 (PDT) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 Date: Sun, 07 Sep 2025 09:25:59 -0700 From: James Gritton To: Konstantin Belousov 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 In-Reply-To: References: <202509042031.584KVpxY000408@gitrepo.freebsd.org> <2f66c886ab44aea5ad2e57cc72c03e3f@freebsd.org> Message-ID: <24a1f2413af24eea3fb5e9be9c05c4bd@freebsd.org> X-Sender: jamie@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2025-09-06 17:26, Konstantin Belousov wrote: > 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. True. An accepted connection changes the network state, both locally and remotely, and automatically establishing that connection wouldn't be the right things to do. The existence of a listen queue also fits well with a notification system that doesn't do its own queueing. Jail descriptors, on the other hand, only exist as a veiw to an existing jail, and don't establish anything other than that view. Jail creation also has no associated queue, so loss-free noficiation relies on the same hack that process forking already established, but requiring a little more in the way of making it fit. An alternate way of solving the problem would be to create such a queue, allowing a single notification of such things as a jail attachment or child jail creation, or possibly more than one of them by the time the process reads the queue. - Jamie