FreeBSD_HEAD_amd64_gcc - Build #1247 - Fixed

FreeBSD_HEAD_amd64_gcc - Build #1247 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1247/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1247/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1247/console

Change summaries:

299960 by hselasky:
Only lock Giant when needed in the LinuxKPI.

Suggested by:	ngie _at_
MFC after:	1 week
Sponsored by:	Mellanox Technologies

299957 by mav:
Reduce verbosity of "now sending synthesized status" message.

MFC after:	1 week

299955 by mav:
No need to check login status for ZOMBIE ports.

ZOMBIE ports are always logged out, and so initiator may try to relogin.

MFC after:	1 weeks

299953 by truckman:
Fix an off by one error to avoid overflowing rp[].

Reported by:	Coverity
CID:		1007579

299952 by truckman:
Increase size of argv[] array to avoid running off the end.

Reported by:	Coverity
CID:		1193819
MFC after:	1 week

299951 by avg:
do not destroy 'snapdir' when it becomes  inactive

That was just wrong.  In fact, we can safely keep this static entry when
it's inactive.
Now the destructive action is moved to the reclaim method and the
function is renamed from zfsctl_snapdir_inactive(0 to
zfsctl_snapdir_reclaim().

Also, we can use gfs_vop_reclaim() instead of gfs_dir_inactive() +
kmem_free().

Lastly, we can just assert that the node does not any children when it
is reclaimed, even on the force unmount.  That's because zfs_umount()
does an extra vflush() pass which should destroy all snapshot-mountpoint
vnodes that are the snapdir's children.

MFC after:	5 weeks

299950 by truckman:
Fix off by one error in index limit calculation

Reported by:	Coverity
CID:		1193826

299949 by avg:
try to recycle "snap" vnodes as soon as possible

Those vnodes should not linger.  "Stale" nodes may get out of
synchronization with actual snapshots.  For example if we destroy a
snapshot and create a new one with the same name.  Or when we rename a
snapshot.

While there fix the argument type for zfsctl_snapshot_reclaim().
Also, its original argument can be passed to gfs_vop_reclaim() directly.

Bug 209093 could be related although I have not specifically verified
that.  Referencing just in case.

PR:		209093
MFC after:	5 weeks

299948 by truckman:
Set retval in the empty password case to avoid a path through the
code that fails to set retval before falling through to the final
return().

Reported by:	emaste
Reported by:	Coverity
CID:		1018711
MFC after:	1 week

299947 by avg:
fix locking in zfsctl_root_lookup

Dropping the root vnode's lock after VFS_ROOT() didn't really help the
fact that we acquired the lock while holding its child's, .zfs, lock
while performing the operaiton.
So, directly use zfs_zget() to get the root vnode.

While there simplify the code in zfsctl_freebsd_root_lookup.
We know that .zfs is always exclusively locked.
We know that there is already a reference on *vpp, so no need for an
extra one.
Account for the fact that .. lookup may ask for a different lock type,
not necessarily LK_EXCLUSIVE.  And handle a possible failure to acquire
the lock given the lock flags.

MFC after:	5 weeks

299946 by avg:
gfs_lookup_dot() does not have to acquire any locks

In fact, that was dangerous.  For example, zfsctl_snapshot_reclaim()
calls gfs_dir_lookup() on ".." path and that ends up calling
gfs_lookup_dot() which violated locking order by acquiring the parent's
directory vnode lock after the child's vnode lock.

Also, the previous behavior was inconsistent as gfs_dir_lookup()
returned a locked vnode for . and .. lookups, but not for any other.

Now gfs_lookup_dot() just references a resulting vnode and the locking
is done in its consumers, where necessary.
Note that we do not enable shared locking support for any gfs / zfsctl
vnodes.

This commit partially reverts r273641.

MFC after:	5 weeks

299945 by avg:
avoid deadlock between zfsctl_snapdir_lookup and zfsctl_snapshot_reclaim

The former acquired a snap vnode lock while holding sd_lock while the
latter does the opposite.

The solution is drop sd_lock before acquiring the vnode lock.  That
should be okay as we are still holding a lock on the 'snapshot'
directory in the exclusive mode.  That lock ensures that there are no
concurrent lookups in the directory and thus no concurrent mount attempts.

But now we have to account for the possibility that the snap vnode
might get reclaim after we drop sd_lock and before we can get
the node lock.  So, check for that case and retry.

MFC after:	5 weeks

299944 by andrew:
Add intrng support to the GICv3 driver. It lacks ITS support so won't handle
MSI or MSI-X interrupts, however this is enought to boot FreeBSD under the
ARM Foundation Model with a GICv3 interrupt controller.

Approved by:	ABT Systems Ltd
Relnotes:	yes
Sponsored by:	The FreeBSD Foundation

299943 by jilles:
libthr(3): Fix xref to _umtx_op(2) now that we have it.

299942 by jilles:
install: Revert utimensat usage (r299850).

This should fix the build on older stable/10, since install is a bootstrap
tool.

Pending a decision how to fix this properly, revert utimensat usage. Copies
with the -p option will again appear older than the original almost always,
but -p is not commonly used.

299941 by andrew:
Call ofw_bus_msimap to find the parent MSI controller, it may not use the
msi-parent property.

Obtained from:	ABT Systems Ltd
Sponsored by:	The FreeBSD Foundation

299940 by avg:
fix a vnode reference leak caused by illumos compat traverse()

This commit partially reverts r273641 which introduced the leak.
It did so to accomodate for some consumers of traverse() that expected
the starting vnode to stay as-is.  But that introduced the leak in the
case when a mounted filesystem was found and its root vnode was
returned.

r299914 removed the troublesome consumers and now there is no reason to
keep the starting vnode.  So, now the new rules are:
- if there is no mounted filesystem, then nothing is changed
- otherwise the starting vnode is always released
- the root vnode of the mounted filesystem is returned locked and
  referenced in the case of success

MFC after:	5 weeks
X-MFC after:	r299914

299939 by andrew:
Move the call to intr_pic_init_secondary to the same place as in the
non-intrng case.

Obtained from:	ABT Systems Ltd
Sponsored by:	The FreeBSD Foundation

299938 by avg:
fix up r299902: mount_snapshot requires that the covered vnode is locked

Previously that was not strictly enforced.

MFC after:	4 weeks
X-MFC with:	r299902