From patchwork Mon Dec 2 17:33:39 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wang Shilong X-Patchwork-Id: 3266341 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 717EE9F373 for ; Mon, 2 Dec 2013 17:33:57 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3B39D20260 for ; Mon, 2 Dec 2013 17:33:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 101DA20254 for ; Mon, 2 Dec 2013 17:33:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752830Ab3LBRdw (ORCPT ); Mon, 2 Dec 2013 12:33:52 -0500 Received: from mail-pd0-f170.google.com ([209.85.192.170]:38599 "EHLO mail-pd0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752663Ab3LBRdv (ORCPT ); Mon, 2 Dec 2013 12:33:51 -0500 Received: by mail-pd0-f170.google.com with SMTP id g10so18575046pdj.15 for ; Mon, 02 Dec 2013 09:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=JRdE7BdInF9ZrJzYXk3k7tT2dfeLunFkQSPyTipD04A=; b=HHKpoGr3byv4VQjKQxwe3zBP0Qh6X/wdjfBwx3OKsNNmdSz9D7KYeCma1e40PKUrHp NKHrwJCNH2UIS/LVwlbidxBMecPMISsr1y9Xy6/AH8j6ZuIFW6MoO7wDCbwdOBQElQZM UMVUCpjfTYNirlcikXQPo/jhabBpJkRcHsD+QQXkMZEmpl9ptLeuLpQwu7Rr7JjCHEvq Xb8JdAuCv0syCNoJIOGV/yeB2dFBZQuglD/yBEJ6IMecBdPx57PfhbsEr1QRJ2uFZVxU D4/f9FzSSvlidnV75nybDJWuhP1wOSrSv/mcVSjo1lZJDjE401zBhd5+u5Z22Ya62sog ZC+g== X-Received: by 10.68.172.65 with SMTP id ba1mr32915416pbc.18.1386005630512; Mon, 02 Dec 2013 09:33:50 -0800 (PST) Received: from linux-b0ol.localdomain ([223.65.189.255]) by mx.google.com with ESMTPSA id ye1sm3510255pab.19.2013.12.02.09.33.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Dec 2013 09:33:49 -0800 (PST) From: Wang Shilong To: linux-btrfs@vger.kernel.org Cc: ochmann@informatik.uni-bonn.de, wangshilong1991@gmail.com, Wang Shilong Subject: [PATCH v3] Btrfs: fix wrong super generation mismatch when scrubbing supers Date: Tue, 3 Dec 2013 01:33:39 +0800 Message-Id: <1386005619-7750-1-git-send-email-wangshilong1991@gmail.com> X-Mailer: git-send-email 1.8.4 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Wang Shilong We came a race condition when scrubbing superblocks, the story is: In commiting transaction, we will update last_trans_commited after writting superblocks. if a scrub start after writting superblocks and before last_trans_commited, generation mismatch happens! We fix it by protecting writting superblock and updating last_trans_commited with tree_log_mutex. Reported-by: Sebastian Ochmann Signed-off-by: Wang Shilong --- Changelog: v2->v3:move tree_log_mutex out of device_list_mutex. v1->v2: use right way to fix the problem. --- fs/btrfs/scrub.c | 11 +++++++---- fs/btrfs/transaction.c | 13 ++++++++++--- 2 files changed, 17 insertions(+), 7 deletions(-) diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c index 561e2f1..a9ed102 100644 --- a/fs/btrfs/scrub.c +++ b/fs/btrfs/scrub.c @@ -2887,6 +2887,7 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start, } + mutex_lock(&fs_info->tree_log_mutex); mutex_lock(&fs_info->fs_devices->device_list_mutex); dev = btrfs_find_device(fs_info, devid, NULL, NULL); if (!dev || (dev->missing && !is_dev_replace)) { @@ -2932,14 +2933,16 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start, atomic_inc(&fs_info->scrubs_running); mutex_unlock(&fs_info->scrub_lock); + /* + * holding tree_log_mutex we can avoid generation mismatch while + * scrubbing superblocks, see comments in commiting transaction + * when updating last_trans_commited. + */ if (!is_dev_replace) { - /* - * by holding device list mutex, we can - * kick off writing super in log tree sync. - */ ret = scrub_supers(sctx, dev); } mutex_unlock(&fs_info->fs_devices->device_list_mutex); + mutex_unlock(&fs_info->tree_log_mutex); if (!ret) ret = scrub_enumerate_chunks(sctx, dev, start, end, diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index c6a872a..052eb22 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -1898,15 +1898,22 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans, goto cleanup_transaction; } + btrfs_finish_extent_commit(trans, root); + + /* + * we must gurantee last_trans_commited update is protected by + * tree_log_mutex with write_ctree_super together, otherwise, + * scubbing super will come in before updating last_trans_commited + * and we will get generation mismatch when scrubbing superblocks. + */ + root->fs_info->last_trans_committed = cur_trans->transid; + /* * the super is written, we can safely allow the tree-loggers * to go about their business */ mutex_unlock(&root->fs_info->tree_log_mutex); - btrfs_finish_extent_commit(trans, root); - - root->fs_info->last_trans_committed = cur_trans->transid; /* * We needn't acquire the lock here because there is no other task * which can change it.