From owner-freebsd-current@freebsd.org Mon May 16 19:31:15 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4505B3E1BF for ; Mon, 16 May 2016 19:31:15 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 853771873; Mon, 16 May 2016 19:31:15 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id E554D1217; Mon, 16 May 2016 19:31:15 +0000 (UTC) Date: Mon, 16 May 2016 19:31:10 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: mav@FreeBSD.org, hselasky@FreeBSD.org, avg@FreeBSD.org, jilles@FreeBSD.org, truckman@FreeBSD.org, andrew@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <226648673.31.1463427075946.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <98231390.19.1463396293089.JavaMail.jenkins@jenkins-9.freebsd.org> References: <98231390.19.1463396293089.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_amd64_gcc - Build #1247 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_amd64_gcc X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 19:31:15 -0000 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 @ 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