Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3727967pxb; Mon, 24 Jan 2022 16:30:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJxjFI4vogLD1hM2zyVXUNaa7yPdRHoW8mjz/PRhu50XOLhGGkiRvUZhJXj3XA9zZofKIbBD X-Received: by 2002:a17:902:7c97:b0:14a:62ed:c296 with SMTP id y23-20020a1709027c9700b0014a62edc296mr16418833pll.42.1643070604417; Mon, 24 Jan 2022 16:30:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643070604; cv=none; d=google.com; s=arc-20160816; b=XTOK09875lsFZAvzqGtgNS59kl4cziKJ5WeAsDofnwtKSjuCk03xDuswLdk0HPx5fU 1AqZzhDJwT98xBXN1c/XARnxM6JS5eAB3ayJdPeiq4dKNodnU9P7Y9r189lEIO4L/qza 4Rv8IQJcY/WrDqfUvNpbNnX4WOb2coEFhYk7OUYyrlyznwVHWgetVx1bu+Kegtt9mjs4 cQdSBueO7XXZpKBUQX4QlWYdrmasFSl7Yd/jXYkVxgrw95dLyNg4JQx5E/j+sIY9RP4C M0WWJUhs25b5x1rsJ52yk1o5xu/TEcbHOt5C8sB5rJghPldYNobMfZS5Eo2zHzEVsPaH rGSw== 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=sfCpZLyzLXdeZbm9Pt+G+zejYWbpotzIeTTDI/CVoNM=; b=Y33v77B/6xCRayBmbyVpIKveD04HhICUnn61n4FaKMoCzebw8Vq753Eqbe4Uz8/+JL ABjv974cLVsRZ3E8K8ktReX1le/iJWeFvWuW/sFAK7HaZfyx2PdcJQk6Ikl2v7vDj71G f0efKtO0vgePfnVjKKHzhmWLexUx38ozhLhONK7N0EgT/+xLu4H+6zrxYuGE3gxV1QKd ii732FIXL9kJGisKERiF+sVPJzewlJCvb0z/zEGkiQMNBKBk6yDkTorVnNgWvJW4xKD7 EAuZoWIaIQXipLuYyo1PipH6splSrpfup/4BCFE+/OeiUtpEgfwPvGd/m6XpGSbT9opN dZUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=uur736XD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d129si2165517pgc.536.2022.01.24.16.29.51; Mon, 24 Jan 2022 16:30:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=uur736XD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S2375671AbiAYAVA (ORCPT + 99 others); Mon, 24 Jan 2022 19:21:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2360320AbiAXXga (ORCPT ); Mon, 24 Jan 2022 18:36:30 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D0E5C0604F1; Mon, 24 Jan 2022 13:37:29 -0800 (PST) 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 ams.source.kernel.org (Postfix) with ESMTPS id 3ACFCB812A7; Mon, 24 Jan 2022 21:37:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 622A7C340E7; Mon, 24 Jan 2022 21:37:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643060247; bh=J08//W2RZ6z3pUMPIZc0DxIQ0L/ndbEORfINNcq+txY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uur736XDGFjDSWG5RIhR5334nuT1ECAIctsUb8wRnPLh3UKwnxr6BHBN9uhKHVpa2 WyXUlgGVFgVAoBPnBHnSFxD46uQ7EApuo3/xuW36bAZ2S8NIm2huPKkWwm9kyzudbU uzfzhNR2TKZRufD28jiwt5MipUgbf5Bxy9jdLkfk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Naohiro Aota , David Sterba Subject: [PATCH 5.16 0886/1039] btrfs: zoned: unset dedicated block group on allocation failure Date: Mon, 24 Jan 2022 19:44:35 +0100 Message-Id: <20220124184155.069409458@linuxfoundation.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220124184125.121143506@linuxfoundation.org> References: <20220124184125.121143506@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Naohiro Aota commit 1ada69f61c88abb75a1038ee457633325658a183 upstream. Allocating an extent from a block group can fail for various reasons. When an allocation from a dedicated block group (for tree-log or relocation data) fails, we need to unregister it as a dedicated one so that we can allocate a new block group for the dedicated one. However, we are returning early when the block group in case it is read-only, fully used, or not be able to activate the zone. As a result, we keep the non-usable block group as a dedicated one, leading to further allocation failure. With many block groups, the allocator will iterate hopeless loop to find a free extent, results in a hung task. Fix the issue by delaying the return and doing the proper cleanups. CC: stable@vger.kernel.org # 5.16 Signed-off-by: Naohiro Aota Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/extent-tree.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -3790,23 +3790,35 @@ static int do_allocation_zoned(struct bt spin_unlock(&fs_info->relocation_bg_lock); if (skip) return 1; + /* Check RO and no space case before trying to activate it */ spin_lock(&block_group->lock); if (block_group->ro || block_group->alloc_offset == block_group->zone_capacity) { - spin_unlock(&block_group->lock); - return 1; + ret = 1; + /* + * May need to clear fs_info->{treelog,data_reloc}_bg. + * Return the error after taking the locks. + */ } spin_unlock(&block_group->lock); - if (!btrfs_zone_activate(block_group)) - return 1; + if (!ret && !btrfs_zone_activate(block_group)) { + ret = 1; + /* + * May need to clear fs_info->{treelog,data_reloc}_bg. + * Return the error after taking the locks. + */ + } spin_lock(&space_info->lock); spin_lock(&block_group->lock); spin_lock(&fs_info->treelog_bg_lock); spin_lock(&fs_info->relocation_bg_lock); + if (ret) + goto out; + ASSERT(!ffe_ctl->for_treelog || block_group->start == fs_info->treelog_bg || fs_info->treelog_bg == 0);