Date: Wed, 10 Sep 2025 12:25:32 -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: <4b63a73ee826d065b6f07771be9c5b37@freebsd.org> In-Reply-To: <aME-zM4Qbtl6efiR@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> <24a1f2413af24eea3fb5e9be9c05c4bd@freebsd.org> <aME-zM4Qbtl6efiR@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2025-09-10 02:03, Konstantin Belousov wrote: > On Sun, Sep 07, 2025 at 09:25:59AM -0700, James Gritton wrote: >> On 2025-09-06 17:26, Konstantin Belousov wrote: >> > On Fri, Sep 05, 2025 at 10:57:30AM -0700, James Gritton wrote: >> 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. > > No, the queue is obviously overkill. Still, no notification system > really require the queue. > > I am not thinking too hard what would be a good design for the jail > filedesc, > but I have some ideas that feels worth communicating. > > ... > > Next, for notifications, the notification subsystem does not need to > indicate what happen, in particular, it does not need to communicate > neither the jid of created (or destroyed) jail, nor jfd for it. It is > enough to make the listener aware that something happen. Upon > receiving > the notification, listener would interrogate the system state and see > what changed. > > The proc knotes are very bad example, in particular, the idea to pass > back the pid is wrong. It is known to be racy, both because reported > pids might get lost, and because pids only behave handle-like in the > parent of the forked child, so pid might be reused. > > Proc knote + half-done procdesc is not a good example to start with. I've given the queuing solution at https://reviews.freebsd.org/D52462 and I'm not particularly happy with it. It's too much code that doesn't really solve the problem. https://reviews.freebsd.org/D52461 goes the non-queue direction, mirroring EVFILT_PROC fork. Yes, I could go even simpler, and not worry about trying to report every transition. I could at least do a best-effort reporting, like how the attach notification currently works, with a pid and also a flag that says something was missed the state needs to be re-examined. That doesn't require any supporting infrastructure and still lets things run quickly in the usual case. - Jamie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4b63a73ee826d065b6f07771be9c5b37>