From owner-freebsd-fs@FreeBSD.ORG Fri Sep 30 18:20:27 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFC6E1065740; Fri, 30 Sep 2011 18:20:27 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) by mx1.freebsd.org (Postfix) with ESMTP id 917CE8FC15; Fri, 30 Sep 2011 18:20:27 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id p8UIKSGj039445; Fri, 30 Sep 2011 11:20:29 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201109301820.p8UIKSGj039445@chez.mckusick.com> To: Attilio Rao In-reply-to: Date: Fri, 30 Sep 2011 11:20:28 -0700 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: Garrett Cooper , freebsd-fs@freebsd.org, Konstantin Belousov , Xin LI Subject: Re: Need to force sync(2) before umounting UFS1 filesystems? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 18:20:27 -0000 > Date: Fri, 30 Sep 2011 15:31:56 +0200 > Subject: Re: Need to force sync(2) before umounting UFS1 filesystems? > From: Attilio Rao > To: Kirk McKusick > Cc: Konstantin Belousov , > Garrett Cooper , > freebsd-fs@freebsd.org, Xin LI > > 2011/9/30 Kirk McKusick : > > > Here is my proposed fix. It does the unroll originally found in the > > non-FORCE case before sleeping waiting for the vfs_busy to clear. > > Is it acceptable to hold the mount mutex while calling VOP_UNLOCK? > > If not, then it needs to be released before the unlock, reacquired > > afterwards, and the check to see if the sleep is needed redone. > > I thought about this approach when sending the e-mail, but there is a > problem: you need to handle the MNTK_UNMOUNT flag checking and > subsequent setting after coveredvnode is held, otherwise at the first > looping you will just return EBUSY. > > You can avoid the unlock by passing PVFS | PDROP. > > Attilio Problem noted. I have updated the patch to clear the MNTK_UNMOUNT (and other flags set above it) after it returns from the sleep. Which means I cannot use the PDROP flag now, but it is good to know about it for future reference. Still not clear to me if it is acceptable to hold the mount mutex while calling VOP_UNLOCK. Should I drop the mount mutex around the VOP_UNLOCK(coveredvp)? Other than that possible problem, this patch appears to solve the EBUSY problem and avoid possible deadlocks. Kirk McKusick Index: sys/kern/vfs_mount.c =================================================================== --- sys/kern/vfs_mount.c (revision 225884) +++ sys/kern/vfs_mount.c (working copy) @@ -1187,6 +1187,7 @@ mtx_assert(&Giant, MA_OWNED); +top: if ((coveredvp = mp->mnt_vnodecovered) != NULL) { mnt_gen_r = mp->mnt_gen; VI_LOCK(coveredvp); @@ -1227,21 +1228,19 @@ mp->mnt_kern_flag |= MNTK_UNMOUNTF; error = 0; if (mp->mnt_lockref) { - if ((flags & MNT_FORCE) == 0) { - mp->mnt_kern_flag &= ~(MNTK_UNMOUNT | MNTK_NOINSMNTQ | - MNTK_UNMOUNTF); - if (mp->mnt_kern_flag & MNTK_MWAIT) { - mp->mnt_kern_flag &= ~MNTK_MWAIT; - wakeup(mp); - } - MNT_IUNLOCK(mp); - if (coveredvp) - VOP_UNLOCK(coveredvp, 0); - return (EBUSY); + if (mp->mnt_kern_flag & MNTK_MWAIT) { + mp->mnt_kern_flag &= ~MNTK_MWAIT; + wakeup(mp); } + if (coveredvp) + VOP_UNLOCK(coveredvp, 0); mp->mnt_kern_flag |= MNTK_DRAINING; error = msleep(&mp->mnt_lockref, MNT_MTX(mp), PVFS, "mount drain", 0); + mp->mnt_kern_flag &= ~(MNTK_UNMOUNT | MNTK_NOINSMNTQ | + MNTK_UNMOUNTF); + MNT_IUNLOCK(mp); + goto top; } MNT_IUNLOCK(mp); KASSERT(mp->mnt_lockref == 0,