MFC r246890:
Close a race relating to setting the PCPU pointer (r13).
MFC r246804:

  Handle (ignore) when a process disappears before it can be tracked.
MFC	r239359:

Remove unused member of struct indir (in_exists) from UFS and EXT2 code.

Discussed with:		mjg
MFC	r246347, r246348, r246349, r246350, r246351, r246352:

ext2fs: Miscellaneous cleanups and fixes.

Use EXT2_LINK_MAX instead of LINK_MAX.
Use nitems().
Correct off-by-one errors in FFTODT() and DDTOFT().
Remove useless rootino local variable.
Remove unused em_e2fsb definition.
Move assignment where it is not dead.

Submitted by:		Christoph Mallon
MFC r246507: sh: Fix a comment.
MFC r246371: sh: Do not test for digit_contig in mksyntax.

ISO/IEC 9899:1999 (E) 5.2.1p3 guarantees that the values of the characters
0123456789 are contiguous.

The generated syntax.c and syntax.h remain the same.

Submitted by:	Christoph Mallon
MFC r246472:
Stop translating the ERESTART error from the open(2) into EINTR.
Posix requires that open(2) is restartable for SA_RESTART.
MFC r246484:
Allow ptrace(2) operation on the child created by vfork(2), if the
debugger is not the parent.
MFC r246801:
Assert that user address is never qremoved.
MFC r246802:
Print slightly more useful information on the 'bad pte' panic.
MFC r246476:
Document the ERESTART translation to EINTR for devfs nodes.
MFC r246485:
Document the detail of interaction between vfork and PT_TRACEME.
MFC r246486:
Document P_PPTRACE.
MFC r246616 and r246759:

- Move scratch data from the USB bus structure to the USB device
structure so that simultaneous access cannot happen. Protect scratch
area using the enumeration lock.
- Reduce stack usage in usbd_transfer_setup() by moving some big stack
members to the scratch area. This saves around 200 bytes of stack.
- Fix a whitespace.
- Protect control requests using the USB device enumeration lock.
- Make sure all callers of usbd_enum_lock() check the return value.
- Remove the control transfer specific lock.
- Bump the FreeBSD version number, hence external USB modules may need
to be recompiled due to a USB device structure change.
MFC r244983 (by jfv):
Add Intel Lynx Point PCH SATA Controller Device IDs
MFC r238379, r238382 (by bruefer):
Renamed the kern.cam.da.da_send_ordered sysctl and tunable to
kern.cam.da.send_ordered, more in line with the other da sysctls/tunables.
Renamed the kern.cam.ada.ada_send_ordered sysctl and tunable to
kern.cam.ada.send_ordered, more in line with the other da sysctls/tunables.

PR:		169765
MFC r230590 (by ken) except parts changing ABI:
Add CAM infrastructure to allow reporting when a drive's long read capacity
data changes.
MFC	r237574:

Ensure crunchen uses the same make binary as the rest of the build.

I actually had already merged the crunchgen part of it as part
of the the enhanced ELF support.

Discussed with:		Simon Gerraty
MFC r236138 (by ken) for recently merged scsi_enc.c:

Work around a race condition in devfs by changing the way closes
are handled in most CAM peripheral drivers that are not handled by
GEOM's disk class.

The usual character driver open and close semantics are that the
driver gets N open calls, but only one close, when the last caller
closes the device.

CAM peripheral drivers expect that behavior to be honored to the
letter, and the CAM peripheral driver code (specifically
cam_periph_release_locked_busses()) panics if it is done incorrectly.

Since devfs has to drop its locks while it calls a driver's close
routine, and it does not have a way to delay or prevent open calls
while it is calling the close routine, there is a race.

The sequence of events, simplified a bit, is:

- devfs acquires a lock
- devfs checks the reference count, and if it is 1, continues to close.
- devfs releases the lock

- 2nd process open call on the device happens here

- devfs calls the driver's close routine

- devfs acquires a lock
- devfs decrements the reference count
- devfs releases the lock

- 2nd process close call on the device happens here

At the second close, we get a panic in
cam_periph_release_locked_busses(), complaining that peripheral
has been released when the reference count is already 0.  This is
because we have gotten two closes in a row, which should not
happen.

The fix is to add the D_TRACKCLOSE flag to the driver's cdevsw, so
that we get a close() call for each open().  That does happen
reliably, so we can make sure that our reference counts are
correct.

Note that the sa(4) and pt(4) drivers only allow one context
through the open routine.  So these drivers aren't exposed to the
same race condition.

scsi_ch.c,
scsi_enc.c,
scsi_enc_internal.h,
scsi_pass.c,
scsi_sg.c:
		For these drivers, change the open() routine to
		increment the reference count for every open, and
		just decrement the reference count in the close.

		Call cam_periph_release_locked() in some scenarios
		to avoid additional lock and unlock calls.

scsi_pt.c:	Call cam_periph_release_locked() in some scenarios
		to avoid additional lock and unlock calls.
MFC r237328 (by ken) for recently merged scsi_enc.c:

Fix several reference counting and object lifetime issues between
the pass(4) and enc(4) drivers and devfs.

The pass(4) driver uses the destroy_dev_sched() routine to
schedule its device node for destruction in a separate thread
context.  It does this because the passcleanup() routine can get
called indirectly from the passclose() routine, and that would
cause a deadlock if the close routine tried to destroy its own
device node.

In any case, once a particular passthrough driver number, e.g.
pass3, is destroyed, CAM considers that unit number (3 in this
case) available for reuse.

The problem is that devfs may not be done cleaning up the previous
instance of pass3, and will panic if isn't done cleaning up the
previous instance.

The solution is to get a callback from devfs when the device node
is removed, and make sure we hold a reference to the peripheral
until that happens.

Testing exposed some other cases where we have reference counting
issues, and those were also fixed in the pass(4) driver.

cam_periph.c:	In camperiphfree(), reorder some of the operations.

		The peripheral destructor needs to be called before
		the peripheral is removed from the peripheral is
		removed from the list.  This is because once we
		remove the peripheral from the list, and drop the
		topology lock, the peripheral number may be reused.
		But if the destructor hasn't been called yet, there
		may still be resources hanging around (like devfs
		nodes) that haven't been fully cleaned up.

cam_xpt.c:	Add an argument to xpt_remove_periph() to indicate
		whether the topology lock is already held.

scsi_enc.c:	Acquire an extra reference to the peripheral during
		registration, and release it once we get a callback
		from devfs indicating that the device node is gone.

		Call destroy_dev_sched_cb() in enc_oninvalidate()
		instead of calling destroy_dev() in the cleanup
		routine.

scsi_pass.c:	Add reference counting to handle peripheral and
		devfs object lifetime issues.

		Add a reference to the peripheral and the devfs
		node in the peripheral registration.

		Don't attempt to add a physical path alias if the
		peripheral has been marked invalid.

		Release the devfs reference once the initial
		physical path alias taskqueue run has completed.

		Schedule devfs node destruction in the
		passoninvalidate(), and release our peripheral
		reference in a new routine, passdevgonecb() once
		the devfs node is gone.  This allows the peripheral
		to fully go away, and the peripheral destructor,
		passcleanup(), will get called.