From patchwork Wed Jun 22 10:18:45 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Anand Jain X-Patchwork-Id: 9192365 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 83C576075C for ; Wed, 22 Jun 2016 10:18:45 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 71FB5283F1 for ; Wed, 22 Jun 2016 10:18:45 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 66D78283F7; Wed, 22 Jun 2016 10:18:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DC790283E6 for ; Wed, 22 Jun 2016 10:18:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751982AbcFVKSe (ORCPT ); Wed, 22 Jun 2016 06:18:34 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:42890 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751236AbcFVKSc (ORCPT ); Wed, 22 Jun 2016 06:18:32 -0400 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u5MAHqnK024408 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Jun 2016 10:17:52 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u5MAHqUu009480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Jun 2016 10:17:52 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u5MAHppo022993; Wed, 22 Jun 2016 10:17:51 GMT Received: from [10.186.101.89] (/10.186.101.89) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 Jun 2016 03:17:50 -0700 Subject: Re: [PATCH v2 2/2] btrfs: wait for bdev put To: Chris Mason , linux-btrfs@vger.kernel.org References: <1465901726-15490-2-git-send-email-anand.jain@oracle.com> <1466504648-2937-1-git-send-email-anand.jain@oracle.com> <0eaf435d-f6e3-31c3-24e2-5a8b1df840a8@fb.com> Cc: holger@applied-asynchrony.com, dsterba@suse.com, xiaolong.ye@intel.com From: Anand Jain Message-ID: <1b7bb28b-939e-c111-9bb0-5091ab1cdcf1@oracle.com> Date: Wed, 22 Jun 2016 18:18:45 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <0eaf435d-f6e3-31c3-24e2-5a8b1df840a8@fb.com> X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Thanks for the review Chris. On 06/21/2016 09:00 PM, Chris Mason wrote: > On 06/21/2016 06:24 AM, Anand Jain wrote: >> From: Anand Jain >> >> Further to the commit >> bc178622d40d87e75abc131007342429c9b03351 >> btrfs: use rcu_barrier() to wait for bdev puts at unmount >> >> This patch implements a method to time wait on the __free_device() >> which actually does the bdev put. This is needed as the user space >> running 'btrfs fi show -d' immediately after the replace and >> unmount, is still reading older information from the device. > > Thanks for working on this Anand. Since it looks like blkdev_put can > deadlock against us, can we please switch to making sure we fully flush > the outstanding IO? It's probably enough to do a sync_blockdev() call > before we allow the unmount to finish, but we can toss in an > invalidate_bdev for good measure. ------------ # git diff BUG_ON(IS_ERR(new_device)); /* -ENOMEM */ ----------- However, theoretically still there might be a problem - at the end of unmount, if the device exclusive open is not actually closed, then there might be a race with another program which is trying to open the device in exclusive mode. Like for eg: unmount /btrfs; fsck /dev/X and here fsck might fail to open the device if it wins the race. > Then we can get rid of the mdelay loop completely, which seems pretty > error prone to me. Yes, the code got little complex here (and also when sysfs fixes were wrote) as struct btrfs_device is getting migrated to a new struct btrfs_device at unmount, which I don't think was necessary? Thanks, Anand > Thanks! > > -chris > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html --- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 604daf315669..e0ad29d6fe9a 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -870,6 +870,11 @@ static void btrfs_close_one_device(struct btrfs_device *device) if (device->missing) fs_devices->missing_devices--; + if (device->bdev && device->writeable) { + sync_blockdev(device->bdev); + invalidate_bdev(device->bdev); + } + new_device = btrfs_alloc_device(NULL, &device->devid, device->uuid);