(cherry picked from commit 32fdcff8703da6f2795193acc77ec3c1fb8b723d)

Reviewed by:	imp, emaste
Differential Revision:	https://reviews.freebsd.org/D41954

(cherry picked from commit 16837d353cdde87672d08112610e51e4121c4e50)

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Similar commit in main:
(cherry picked from commit d0b2dbfa0ecf)

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

Similar commit in main:
(cherry picked from commit 1d386b48a555)

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with:		pfg
MFC After:		3 days
Sponsored by:		Netflix

(cherry picked from commit 4d846d260e2b9a3d4d0a701462568268cbfe7a5b)

They can fail when run in parallel since they all share a global queue
key.

MFC after:	1 week

(cherry picked from commit e1ccf64b884a1a47c48a2fb7d71e7eb18347c6d6)

Require the newly opened file descriptor to be good, instead of
re-requiring the one that was required three lines earlier.
Thankfully, opening /dev/null is really unlikely to fail.

Reported by:	Coverity
MFC after:	1 week
Sponsored by:	Dell EMC Isilon

(cherry picked from commit a8fea07c3053293f35e00b9073b33ff6f1d9a067)

The default behavior for attaching processes to jails is that the jail's
cpuset augments the attaching processes, so that it cannot be used to
escalate a user's ability to take advantage of more CPUs than the
administrator wanted them to.

This is problematic when root needs to manage jails that have disjoint
sets with whatever process is attaching, as this would otherwise result
in a deadlock. Therefore, if we did not have an appropriate common
subset of cpus/domains for our new policy, we now allow the process to
simply take on the jail set *if* it has the privilege to widen its mask
anyways.

With the new logic, root can still usefully cpuset a process that
attaches to a jail with the desire of maintaining the set it was given
pre-attachment while still retaining the ability to manage child jails
without jumping through hoops.

A test has been added to demonstrate the issue; cpuset of a process
down to just the first CPU and attempting to attach to a jail without
access to any of the same CPUs previously resulted in EDEADLK and now
results in taking on the jail's mask for privileged users.

PR:		253724

(cherry picked from commit 60c4ec806dfd0f79edf8ca3abc04bbb69c0418f7)

The cpuset(2) tests should be run as root (require.user properly set) with
>= 3 cpus for maximum coverage. All tests that want to modify the cpuset
don't assume any particular cpu layout (i.e. the first cpu may not be 0, the
last may not be first + count) and the following scenarios are tested:

1.) newset: basic execute cpuset() to grab a new cpuset, make sure the
    assigned cpuset then has a different ID.
2.) transient: create a new cpuset then assign the process its original
    cpuset, ensuring that the one we created is now gone.
3.) deadlk: test assigning an anonymous mask, then resetting the process
    base affinity with 1-cpu overlap w.r.t. the anonymous mask and with
    0-cpu overlap w.r.t. the anonymous mask.
4.) jail_attach_newbase: process attaches to a jail with its own
    cpuset+mask (e.g. cpuset -c -l 1,2 jail -c path=/ command=/bin/sh)
5.) jail_attach_newbase_plain: process attaches to a jail with its own
    cpuset (e.g. cpuset -c jail -c path=/ command=/bin/sh)
6.) jail_attach_prevbase: process attaches to a jail with the containing
    jail's root cpuset (e.g. jail -c path=/ command=/bin/sh)
7.) jail_attach_plain: process attaches to a jail with the containing jail's
    root cpuset+mask.
8.) badparent: creates a new cpuset and modifies the anonymous thread mask,
    then setid's back to the original and checks that cpuset_getid() returns
    the expected set.

Differential Revision:	https://reviews.freebsd.org/D27307

MFC after:	2 weeks