Date: Sun, 07 Sep 2025 09:25:59 -0700 From: James Gritton <jamie@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> 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: <24a1f2413af24eea3fb5e9be9c05c4bd@freebsd.org> In-Reply-To: <aLzRSTtSdzSJ5tOn@kib.kiev.ua> References: <202509042031.584KVpxY000408@gitrepo.freebsd.org> <aLokHDP-EMa1LR0D@kib.kiev.ua> <da6b56365c188ce55bb4e878636bc911@freebsd.org> <aLpxozYUfi_S-U7b@kib.kiev.ua> <2f66c886ab44aea5ad2e57cc72c03e3f@freebsd.org> <aLzRSTtSdzSJ5tOn@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24a1f2413af24eea3fb5e9be9c05c4bd>