MFC r248294, r248296:

r248294 (pjd):

Delete requests can be larger than MAXPHYS.

r248296 (pjd):

Minor corrections.


git-svn-id: svn://svn.freebsd.org/base/stable/9@252517 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
MFC r248286 (pjd):

Removed redundant includes.


git-svn-id: svn://svn.freebsd.org/base/stable/9@252519 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
MFC r252380:
Unbreak "zfs jail" and "zfs unjail" (broken in stable/9 since r249643)

I missed to register zfs_ioc_jail and zfs_ioc_unjail as legacy ioctl's
with the new zfs_ioctl_register_legacy() function.

These operations do not modify pools or datasets so there is no need to
log them to pool history.

Reported by:	Alexander Leidinger <netchild@FreeBSD.org> on current@


git-svn-id: svn://svn.freebsd.org/base/stable/9@252524 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
When a previous call to sbsndptr() leaves sb->sb_sndptroff at the start of an
mbuf that was fully consumed by the previous call, the mbuf ptr returned by the
current call ends up being the previous mbuf in the sb chain to the one that
contains the data we want.

This does not cause any observable issues because the mbuf copy routines happily
walk the mbuf chain to get to the data at the moff offset, which in this case
means they effectively skip over the mbuf returned by sbsndptr().

We can't adjust sb->sb_sndptr during the previous call for this case because the
next mbuf in the chain may not exist yet. We therefore need to detect the
condition and make the adjustment during the current call.

Fix by detecting the special case of moff being at the start of the next mbuf in
the chain and adjust the required accounting variables accordingly.

Reviewed by:	andre


git-svn-id: svn://svn.freebsd.org/base/stable/9@252532 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
MFC r251732,251752:

Add support for non-virtualised hhook points, which are uniquely identified by
type and id, as compared to virtualised hook points which are now uniquely
identified by type, id and a vid (which for vimage is the pointer to the vnet
that the hhook resides in).

All hhook_head structs for both virtualised and non-virtualised hook points
coexist in hhook_head_list, and a separate list is maintained for hhook points
within each vnet to simplify some vimage-related housekeeping.

Reviewed by:	scottl


git-svn-id: svn://svn.freebsd.org/base/stable/9@252534 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Merge remote-tracking branch 'upstream/svn_stable_9' into svn_stable_9