Looks good - nothing to add.

In D28952#648403, @kevans wrote:

This is still a necessary change, it's just not the only one we need; I suspect both jail(8) and jexec(8) should try to switch to their root's id before running commands in a jail, so that administratively spawned stuff ends up with the jail's full mask.

In D28952#648403, @kevans wrote:

I suspect both jail(8) and jexec(8) should try to switch to their root's id before running commands in a jail, so that administratively spawned stuff ends up with the jail's full mask.

(edit) e.g., https://people.freebsd.org/~kevans//jail-cpuset.diff which accomplishes this for jail(8) on start/stop.

In D28952#648302, @kevans wrote:

In D28952#648283, @jamie wrote:

But how about this: first at least try using the intersection of the current and jail sets (whether or not currently jailed), and only as a EDEADLK fallback punt to just using the jailed set.

Yeah, I think that makes sense -- we're talking about EDEADLK fallback if the priv is also set, so that it naturally gets cpuset down if it can?

In D28952#648262, @jamie wrote:

This might be a reason to keep PRIV_JAIL_CPUSET, and have it generally be available to virtual as well as real root.

In D28952#648258, @me_igalic.co wrote:

how does this, or the current approach apply to jails in jails (which are under a specific CPU set?

Might PRIV_SCHED_CPUSET be sufficient for this? If a process has the ability to explicitly expand the current cpu list, it makes sense for it to be able to implicitly do so when attaching to a jail.

In D24570#616031, @netchild wrote:

Would it make sense to be able to override the path (BTW: /etc/jail.conf.d would be my preference), in the sense of having it as a variable in /etc/defaults/rc.conf (would this help in the netboot case)?
Would it make sense to make this a list,, so that I could do e.g. jail_conf_dir="/etc/jail.conf.d /usr/local/etc/jail.conf.d"?

In D28150#647893, @kevans wrote:

So, I'm going to ask a stupid question here; what all *actually* breaks if we end up with duplicate jids?

All previous work has been committed now (not without hiccups). This is the final-ish patch that only handles the main intent of the project.

Sorry I took so long - I confused your note that it should be reverted with a note that it *had been* reverted.

Updated for cc7b73065302 and d4380c0cdd05.

Updated for cc7b73065302 and d4380c0cdd05.

Updated for cc7b73065302 and d4380c0cdd05.

Updated for cc7b73065302 and d4380c0cdd05.

Updated for cc7b73065302 and d4380c0cdd05.

Updated for cc7b73065302 and d4380c0cdd05.

This is now the culmination of D28419, D27876, D28458, D28473, and D28515. The only thing remaining in this patch is the part that doesn't resurrect dying jails via jail_set, and instead renumbers the dying jails as necessary, and the userspace/man changes from before.

Fix up prison_deref_kill, which had some typos in which prison it was acting on. Also move prisons off of their parent's child lists along with the loop instead of all at the end.

A new version, built on top of D28419, and updated with other recent jail changes. With the addition of prison_isvalid() and prison_isalive(), the changes are significantly reduced.

Update for c050ea803eaa and add suggested mtx_assert.

In D28150#634852, @bz wrote:

I am not sure I like the idea of making jid's a first-class citizen just because our mgmt interface once did and we kept it for historic purpose and backward compat and habits are hard to change.

I am also not entirely opposed to the idea.

Update for various changes recently checked in to kern_jail.c.

It doesn't really make sense for this to be a separate revision, considering it's part of D28150 which overwrites much of the change here. So I'm rolling it all into a single revision instead.

Add full context to diffs

Add full context diff for kern_jail.c

Updated for 2a4b22514635

Well it certainly works as expected, but then you knew that :-).

As I had hoped, it took away the expected problem of attaching to a jail (when the process doesn't have its own visible cpuset), and ending up with the process still having its old root cpuset (though under a new anonymous masked bit). That was the real problem I see with the current setup (not that what I didn't see aren't problems as well, but at least there was something I noticed ;-).

It looks to be working correctly on a quick run-through.