Jail descriptor kevents, Plan B
AbandonedPublic
Actions

Authored by jamie on Tue, Sep 9, 4:37 PM.

Details

Reviewers: None

Summary

Jails have kevent support, with events for set, attach, remove, and child creation. The last one allows for child jails to be automatically added to the vent list via the NOTE_TRACK that was already used by process forking.

Jail descriptors can also easily be tracked via kevent, but have a harder time with child jail tracking because kevent isn't able to open new jail descriptors (as they are process-specific). So something needs to be done to work around this.

Plan B: kevent only returns NOTE_JAIL_CHILD (without an identifier), indicating that a child jail was created. Separately, there is a set of ioctls to automatically add descriptors for child (and further descendant) jails as they are created, and to fetch those descriptors. It's only when the process fetches the descriptor that is actually shows up the process's file table. While it's technically unrelated, the ioctl works together with kevent so new jails can notify and get a descriptor.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

jamie created this revision.Tue, Sep 9, 4:37 PM

Herald added subscribers: olce, imp. · View Herald TranscriptTue, Sep 9, 4:37 PM

jamie requested review of this revision.Tue, Sep 9, 4:37 PM

Plan A is in D52461.

Advantages of Plan B: Newly created jails are presented as descriptors, which is likely what the caller expects, as they are handling the parent jail through a descriptor. Even before the program fetches the jail to user space, it still queues other created jails as well.

Disadvantages of Plan B: While new jaildescs are created automatically, the caller must add the descriptors to kevent tracking themselves. This means there's a possibility of missed events, though jail removal will still be noted at the start of tracking and new child jails can be checked for via the same ioctl. There's a significant amount of new kernel code, which is risky this close to release.

I had considered a Plan C, the solved all the races with kevent returning a new tracked jail descriptor, but that turned out to only solve most of the races, and had even more new code, including jail-descriptor-specific code added to kevent(2). So I discarded that plan as not feasible.

jamie mentioned this in D52461: Jail descriptor kevents, Plan A.Tue, Sep 9, 4:57 PM

crest_freebsd_rlwinm.de added a subscriber: crest_freebsd_rlwinm.de.Tue, Sep 9, 7:17 PM

Commit 66d8ffe30 has simpler kevent handling for jaildesc, without any recursion. Jail kevents have also have recussion removed. Its lack of guarantees and incomplete problem-solving meant that applications would need a way to handle when notifications weren't 100% collected. As long as that's the case, might as well get rid of the complexity.

The non-recursive kevents decided on, which are identical for jid-based and descriptor-based events, report a child creation event with the jid in the data, same as how the pid is in the data for attach events. And likewise, if more than one jail is created, the renamed NOTE_JAIL_MULTI flagfs is set. Now that there are two different event types using this, the data is set to zero in that situation instead of that last reported id.