From patchwork Tue Jul 30 20:34:35 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 2835923 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 8FD789F7D6 for ; Tue, 30 Jul 2013 20:34:44 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9AF7F20263 for ; Tue, 30 Jul 2013 20:34:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AFA3020257 for ; Tue, 30 Jul 2013 20:34:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757294Ab3G3Uej (ORCPT ); Tue, 30 Jul 2013 16:34:39 -0400 Received: from dkim2.fusionio.com ([66.114.96.54]:42537 "EHLO dkim2.fusionio.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757122Ab3G3Uei (ORCPT ); Tue, 30 Jul 2013 16:34:38 -0400 Received: from mx1.fusionio.com (unknown [10.101.1.160]) by dkim2.fusionio.com (Postfix) with ESMTP id C0A449A0693 for ; Tue, 30 Jul 2013 14:34:37 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fusionio.com; s=default; t=1375216477; bh=P4YOFY2UKp83zeVHh9nBw0MNZ9GwJ7aHWKBpZapm1J4=; h=From:To:Subject:Date; b=q8UikJa1sR1O3GrkXtGdUsynWIVFcHtyw2HMXUOWYxYQGk+zU6IbQAiYq1Nj4zgkV dpTe8vcK5NlPelvE/nBbadAOrUbd35FrAFDn5SXnVfA6/uBHlYNrxaTM9HCwDv09hJ 1MIAJzCUdj42JdxvzQwTTPdleKdN0nzXnNAo+lLM= X-ASG-Debug-ID: 1375216477-03d6a577cb3e40a0001-6jHSXT Received: from CAS2.int.fusionio.com (cas2.int.fusionio.com [10.101.1.41]) by mx1.fusionio.com with ESMTP id 4X6m4Akha08Y2tJC (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 30 Jul 2013 14:34:37 -0600 (MDT) X-Barracuda-Envelope-From: JBacik@fusionio.com Received: from localhost (10.101.1.160) by mail.fusionio.com (10.101.1.41) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 30 Jul 2013 14:34:36 -0600 From: Josef Bacik To: Subject: [PATCH] Btrfs: change how we queue blocks for backref checking Date: Tue, 30 Jul 2013 16:34:35 -0400 X-ASG-Orig-Subj: [PATCH] Btrfs: change how we queue blocks for backref checking Message-ID: <1375216475-31796-1-git-send-email-jbacik@fusionio.com> X-Mailer: git-send-email 1.7.7.6 MIME-Version: 1.0 X-Originating-IP: [10.101.1.160] X-Barracuda-Connect: cas2.int.fusionio.com[10.101.1.41] X-Barracuda-Start-Time: 1375216477 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://10.101.1.180:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at fusionio.com X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0203 X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.137447 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-8.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, 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 Previously we only added blocks to the list to have their backrefs checked if the level of the block is right above the one we are searching for. This is because we want to make sure we don't add the entire path up to the root to the lists to make sure we process things one at a time. This assumes that if any blocks in the path to the root are going to be not checked (shared in other words) then they will be in the level right above the current block on up. This isn't quite right though since we can have blocks higher up the list that are shared because they are attached to a reloc root. But we won't add this block to be checked and then later on we will BUG_ON(!upper->checked). So instead keep track of wether or not we've queued a block to be checked in this current search, and if we haven't go ahead and queue it to be checked. This patch fixed the panic I was seeing where we BUG_ON(!upper->checked). Thanks, Signed-off-by: Josef Bacik --- fs/btrfs/relocation.c | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c index 8168fb3..2ec59c4 100644 --- a/fs/btrfs/relocation.c +++ b/fs/btrfs/relocation.c @@ -696,6 +696,7 @@ struct backref_node *build_backref_tree(struct reloc_control *rc, int cowonly; int ret; int err = 0; + bool need_check = true; path1 = btrfs_alloc_path(); path2 = btrfs_alloc_path(); @@ -919,6 +920,7 @@ again: cur->bytenr); lower = cur; + need_check = true; for (; level < BTRFS_MAX_LEVEL; level++) { if (!path2->nodes[level]) { BUG_ON(btrfs_root_bytenr(&root->root_item) != @@ -962,14 +964,12 @@ again: /* * add the block to pending list if we - * need check its backrefs. only block - * at 'cur->level + 1' is added to the - * tail of pending list. this guarantees - * we check backrefs from lower level - * blocks to upper level blocks. + * need check its backrefs, we only do this once + * while walking up a tree as we will catch + * anything else later on. */ - if (!upper->checked && - level == cur->level + 1) { + if (!upper->checked && need_check) { + need_check = false; list_add_tail(&edge->list[UPPER], &list); } else