Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp3932699rwi; Sat, 22 Oct 2022 02:27:10 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6WJOFNM7lEQYvsHygrtIbqLJzDwxutK9xWMyRUBkzQpqCsgwnCOINAClp6JZLTmGmL1Znr X-Received: by 2002:a17:906:fe49:b0:73d:70c5:1a52 with SMTP id wz9-20020a170906fe4900b0073d70c51a52mr19408267ejb.469.1666430829811; Sat, 22 Oct 2022 02:27:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666430829; cv=none; d=google.com; s=arc-20160816; b=LZ7Nf8UCGXwDHKdLXjt2E8MR5Mvb3zCaU3EtJMac3pJ+JYV1Fe4r/GawCNDI8Z/OIz DlBqHPZkqK6yAC7Rby5RnS0iwFuLRphf5MCJZYYejStX0vJ3W327kJO+rkisg8bGsGzV RNmBfPw/pBa0o57ptPXjUxyqVaOlG+O0E3R9F7tIG0FYlDruYA3mfNqvIZ82L61IDVgG MYmW5mPUpyCr4FFNxnwP/4zfGDMFAGOo1oeXSnGNcDIuRusvNtDh+LfMOBpDsxjfxSrz AvdidqGGiJOT2ehfUPp0AWZwz3Swot/xZPp8YwTirJ2Xpc/eMOK3HL4Of2D/ka9IBLnx Kjtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=wytThTImOBRPJ0d12pVMCynEebnkKc7zTfPv9FhUm84=; b=fDlMotT6I8SDL8Gh/+P27yc4ofS1iZsfALJV9aq/LoGzAM3RXKqHBUhxExDBaUyPIo zhi45z59fa2VYuh5W3zTEtOl5aEq/Yf6VRLuNCzGbFGpbz/dBz4hiK6JdQnF9m6ixAqi laNqwuBonXk3QjFzomNddHTj8yrnOTjBaTRM7tx+VzfJKLjPIk3zWFahz+Ry6xbJk17g W6KmGzMlcHe8Q2tFhyswapuoThvfwnASCjP3lc3crkBV8qnqGVd7Uqz5T50KClMsV6JW Bb0T5RHG/9M62uOZEpQ2kAzMzFURjuCuPscHRqeKFWYdSLR3qUOdR6BF74VFDpVQBbBl cOYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="Na9M/vZP"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s11-20020a056402014b00b0045ca331c2ebsi19175595edu.232.2022.10.22.02.26.44; Sat, 22 Oct 2022 02:27:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="Na9M/vZP"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235055AbiJVJAs (ORCPT + 99 others); Sat, 22 Oct 2022 05:00:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37036 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235173AbiJVI7U (ORCPT ); Sat, 22 Oct 2022 04:59:20 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A7B9295B1F; Sat, 22 Oct 2022 01:16:19 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3E44F60B23; Sat, 22 Oct 2022 08:04:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 40393C433C1; Sat, 22 Oct 2022 08:04:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666425881; bh=68QUrxDYF+PVlFxrrny2cf5HOMi/5kXxGhpmdQA+QS0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Na9M/vZPiCzv5xFqRVLiJnppF0aEVWQtqopCGDV/5Qz1mN6frcoUICehK6Uu3Rifk +N3Pr6lqkS3Nm/kRzAemTEd4qcAZGfeDVqodOgeQSiw4+2/p1n+pQeW9cUn0mqOnCV 0shRMDaGJu+ZxK7eOkSPmCN79oHJw/HRdzzmib6Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josef Bacik , David Sterba , Sasha Levin Subject: [PATCH 5.19 646/717] btrfs: call __btrfs_remove_free_space_cache_locked on cache load failure Date: Sat, 22 Oct 2022 09:28:45 +0200 Message-Id: <20221022072527.027923827@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221022072415.034382448@linuxfoundation.org> References: <20221022072415.034382448@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Josef Bacik [ Upstream commit 8a1ae2781dee9fc21ca82db682d37bea4bd074ad ] Now that lockdep is staying enabled through our entire CI runs I started seeing the following stack in generic/475 ------------[ cut here ]------------ WARNING: CPU: 1 PID: 2171864 at fs/btrfs/discard.c:604 btrfs_discard_update_discardable+0x98/0xb0 CPU: 1 PID: 2171864 Comm: kworker/u4:0 Not tainted 5.19.0-rc8+ #789 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfs_work_helper RIP: 0010:btrfs_discard_update_discardable+0x98/0xb0 RSP: 0018:ffffb857c2f7bad0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8c85c605c200 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffffff86807c5b RDI: ffffffff868a831e RBP: ffff8c85c4c54000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8c85c66932f0 R11: 0000000000000001 R12: ffff8c85c3899010 R13: ffff8c85d5be4f40 R14: ffff8c85c4c54000 R15: ffff8c86114bfa80 FS: 0000000000000000(0000) GS:ffff8c863bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2e7f168160 CR3: 000000010289a004 CR4: 0000000000370ee0 Call Trace: __btrfs_remove_free_space_cache+0x27/0x30 load_free_space_cache+0xad2/0xaf0 caching_thread+0x40b/0x650 ? lock_release+0x137/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_is_held_type+0xe2/0x140 process_one_work+0x271/0x590 ? process_one_work+0x590/0x590 worker_thread+0x52/0x3b0 ? process_one_work+0x590/0x590 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 This is the code ctl = block_group->free_space_ctl; discard_ctl = &block_group->fs_info->discard_ctl; lockdep_assert_held(&ctl->tree_lock); We have a temporary free space ctl for loading the free space cache in order to avoid having allocations happening while we're loading the cache. When we hit an error we free it all up, however this also calls btrfs_discard_update_discardable, which requires block_group->free_space_ctl->tree_lock to be held. However this is our temporary ctl so this lock isn't held. Fix this by calling __btrfs_remove_free_space_cache_locked instead so that we only clean up the entries and do not mess with the discardable stats. Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Sasha Levin --- fs/btrfs/free-space-cache.c | 53 +++++++++++++++++++++++++++----------------- 1 file changed, 33 insertions(+), 20 deletions(-) --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -48,6 +48,25 @@ static void bitmap_clear_bits(struct btr struct btrfs_free_space *info, u64 offset, u64 bytes, bool update_stats); +static void __btrfs_remove_free_space_cache_locked( + struct btrfs_free_space_ctl *ctl) +{ + struct btrfs_free_space *info; + struct rb_node *node; + + while ((node = rb_last(&ctl->free_space_offset)) != NULL) { + info = rb_entry(node, struct btrfs_free_space, offset_index); + if (!info->bitmap) { + unlink_free_space(ctl, info, true); + kmem_cache_free(btrfs_free_space_cachep, info); + } else { + free_bitmap(ctl, info); + } + + cond_resched_lock(&ctl->tree_lock); + } +} + static struct inode *__lookup_free_space_inode(struct btrfs_root *root, struct btrfs_path *path, u64 offset) @@ -881,7 +900,14 @@ out: return ret; free_cache: io_ctl_drop_pages(&io_ctl); - __btrfs_remove_free_space_cache(ctl); + + /* + * We need to call the _locked variant so we don't try to update the + * discard counters. + */ + spin_lock(&ctl->tree_lock); + __btrfs_remove_free_space_cache_locked(ctl); + spin_unlock(&ctl->tree_lock); goto out; } @@ -1007,7 +1033,13 @@ int load_free_space_cache(struct btrfs_b if (ret == 0) ret = 1; } else { + /* + * We need to call the _locked variant so we don't try to update + * the discard counters. + */ + spin_lock(&tmp_ctl.tree_lock); __btrfs_remove_free_space_cache(&tmp_ctl); + spin_unlock(&tmp_ctl.tree_lock); btrfs_warn(fs_info, "block group %llu has wrong amount of free space", block_group->start); @@ -2970,25 +3002,6 @@ static void __btrfs_return_cluster_to_fr btrfs_put_block_group(block_group); } -static void __btrfs_remove_free_space_cache_locked( - struct btrfs_free_space_ctl *ctl) -{ - struct btrfs_free_space *info; - struct rb_node *node; - - while ((node = rb_last(&ctl->free_space_offset)) != NULL) { - info = rb_entry(node, struct btrfs_free_space, offset_index); - if (!info->bitmap) { - unlink_free_space(ctl, info, true); - kmem_cache_free(btrfs_free_space_cachep, info); - } else { - free_bitmap(ctl, info); - } - - cond_resched_lock(&ctl->tree_lock); - } -} - void __btrfs_remove_free_space_cache(struct btrfs_free_space_ctl *ctl) { spin_lock(&ctl->tree_lock);