Re: git: 851dc7f859c2 - main - jail: add jail descriptors

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