Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2243568imm; Thu, 7 Jun 2018 07:36:29 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLhWjgZZ2I4+VY6KH67aTDWo+m2ElPRLUwkDMLC0JzNqJgKJnUEJ+GO0Z7SiF6Q+IOqXGF2 X-Received: by 2002:a63:a702:: with SMTP id d2-v6mr1869421pgf.246.1528382189631; Thu, 07 Jun 2018 07:36:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528382189; cv=none; d=google.com; s=arc-20160816; b=0JtlGJCGwoam6sJ8FlhZ4Cde5dyFLHg1OQ8tav/1Fc1uOboOjT0f8bCbEQkyToSpn/ DqGPqF6ctQzpPfBSdlcp5LlYYKhfLWtysipmL83ro2Gn/hdf27DDiITFuTWFhKlCDbT0 oLLS0KmzVJXaixdJY7SpfLOsFpdPWzbtz/VjNU/SyD5bOaW5XffEnofmnUS2xlsW8ajs YdJbXYMRkcnbejifMMM2D8MZdh1oodaUYvDcKazyodvKi/sbGQhxCZrR0carr6LsCEOT DcKf8ZHqE0cdnKmKYEeJVifKk45N4n37ICu08DD5anuPmCFt0eHoOsp+CKBKc4EM6kVm T/dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=EYLLtZWl+o4SRoPyhFr7zM2J/bH70Mf6r7TCgyF4K2I=; b=pdKrWIfAsMRPMbzzTmQNs9Su64xnQWneeFC6lTAQ/SI8a+QlQ1NiSRBZLfvXiuh9BE 7bIrAGUYsBRT7bHcq6QVI3ErAgmQ+L/Hwo5eyt9estSvDnA7/7m9Lp2+hwuGz2fBUXN7 HPsOAyZMHZA1ApkAlMsIJvw9lP4b31l4JUHzzYvWg5zx9xE3QEWuNmJn92kcywyf8JO9 vI84d47/1G527o2awo6whVpj6hBwuxgZWXOTxeCJdR7sBln7P+bublsbQJSknf83HwBx 3GrVES+eDImqhjs4S7VnzRbiILssgw1JbWDQLkPavoanrW/UF3dOacy0cB8UXJ2iJgyi Jl7g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l4-v6si54268577plb.213.2018.06.07.07.36.15; Thu, 07 Jun 2018 07:36:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934017AbeFGOfE (ORCPT + 99 others); Thu, 7 Jun 2018 10:35:04 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:40369 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934005AbeFGOe4 (ORCPT ); Thu, 7 Jun 2018 10:34:56 -0400 Received: from [148.252.241.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fQvbj-0005Zi-8L; Thu, 07 Jun 2018 15:09:43 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1fQvb5-0002yf-Cq; Thu, 07 Jun 2018 15:09:03 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Zygo Blaxell" , "David Sterba" , "Lu Fengqi" Date: Thu, 07 Jun 2018 15:05:21 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 190/410] btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes In-Reply-To: X-SA-Exim-Connect-IP: 148.252.241.226 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.57-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Zygo Blaxell commit c8195a7b1ad5648857ce20ba24f384faed8512bc upstream. Until v4.14, this warning was very infrequent: WARNING: CPU: 3 PID: 18172 at fs/btrfs/backref.c:1391 find_parent_nodes+0xc41/0x14e0 Modules linked in: [...] CPU: 3 PID: 18172 Comm: bees Tainted: G D W L 4.11.9-zb64+ #1 Hardware name: System manufacturer System Product Name/M5A78L-M/USB3, BIOS 2101 12/02/2014 Call Trace: dump_stack+0x85/0xc2 __warn+0xd1/0xf0 warn_slowpath_null+0x1d/0x20 find_parent_nodes+0xc41/0x14e0 __btrfs_find_all_roots+0xad/0x120 ? extent_same_check_offsets+0x70/0x70 iterate_extent_inodes+0x168/0x300 iterate_inodes_from_logical+0x87/0xb0 ? iterate_inodes_from_logical+0x87/0xb0 ? extent_same_check_offsets+0x70/0x70 btrfs_ioctl+0x8ac/0x2820 ? lock_acquire+0xc2/0x200 do_vfs_ioctl+0x91/0x700 ? __fget+0x112/0x200 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x23/0xc6 ? trace_hardirqs_off_caller+0x1f/0x140 Starting with v4.14 (specifically 86d5f9944252 ("btrfs: convert prelimary reference tracking to use rbtrees")) the WARN_ON occurs three orders of magnitude more frequently--almost once per second while running workloads like bees. Replace the WARN_ON() with a comment rationale for its removal. The rationale is paraphrased from an explanation by Edmund Nadolski on the linux-btrfs mailing list. Fixes: 8da6d5815c59 ("Btrfs: added btrfs_find_all_roots()") Signed-off-by: Zygo Blaxell Reviewed-by: Lu Fengqi Signed-off-by: David Sterba [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings --- fs/btrfs/backref.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/fs/btrfs/backref.c +++ b/fs/btrfs/backref.c @@ -979,7 +979,16 @@ again: while (!list_empty(&prefs)) { ref = list_first_entry(&prefs, struct __prelim_ref, list); - WARN_ON(ref->count < 0); + /* + * ref->count < 0 can happen here if there are delayed + * refs with a node->action of BTRFS_DROP_DELAYED_REF. + * prelim_ref_insert() relies on this when merging + * identical refs to keep the overall count correct. + * prelim_ref_insert() will merge only those refs + * which compare identically. Any refs having + * e.g. different offsets would not be merged, + * and would retain their original ref->count < 0. + */ if (roots && ref->count && ref->root_id && ref->parent == 0) { /* no parent == root of tree */ ret = ulist_add(roots, ref->root_id, 0, GFP_NOFS);