Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1862074pxp; Mon, 7 Mar 2022 04:06:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJwCZdn2DoV/T4CIHcPaLi6bGWCXAALTwSbrohc0ZUXDVkER4IQgp4TleRFx2FmR5ARHoyE8 X-Received: by 2002:a63:1849:0:b0:380:3aee:496a with SMTP id 9-20020a631849000000b003803aee496amr4349823pgy.489.1646654810241; Mon, 07 Mar 2022 04:06:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646654810; cv=none; d=google.com; s=arc-20160816; b=IK2/eJieIbSSArCu3fdejSR7GCXOiaAc0pfxZFKrki3seL74bvD9EVvSAFQk79GwiY 0iSeAKQrYB8TGaK++ho7xU1JVMLQ5/afKJhhDxNWrPq8w0kmr66sec5dCc5STbC2mwGx SSMpVz0+Zlz3G+1h6yx/cV3iXKhp9XzL4irjm+urRUWqtJPtsbVJy0y89AwVP9mYvBjm fG5nrIO8l2mEltkeFR73L5Q5r1foH9CfC+tzPUuIWilk0iM8bg67KkBl4uiwXuGJGLWN pzA82fwjUDz5HxYRKSDaUqxUyGE5LFPLSyqmSlYmxYYNRyRsJ+tqMyHC3cAoqqhUkfcw qLsQ== 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=Mm0vxwUJu2zNh7Ki2T6uw8fxn0pjd3tsSc/3Nswuc0s=; b=y2OSrvoQKtgqzISLny6Bm6VtfBrrhG/guytkDXyCygRP/C0RPb/zFaRHLIIG5nXP2k GUh911tj5qVBzz63z7ReGc4dxIa4R+AqmqZ/bdruaAzQL2HhXbGkv54vA2x5my6hAUyN BjPfUJi85uEP4Bdqi3ueKbhiN8Q/icbivsY3sD2HnrO5kZxiQoAaxT8n7ACsI9q4cePO y1hwmAND1R6dbZjYMh48FmLsy5aaQ+ayVLqlA6tP4f5qZxblwwB1XCsj5t75cq23E506 8HObFMORzgsB0jQo1pUeJLl2lVXP2sh5BMkaGR/UNNC+8mVvatTjjuOR7svPeir4T+O2 Q7Mw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=hPpGKoeC; 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 62-20020a630141000000b0037c3f657d6asi12073422pgb.151.2022.03.07.04.06.32; Mon, 07 Mar 2022 04:06:50 -0800 (PST) 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=hPpGKoeC; 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 S239344AbiCGKRK (ORCPT + 99 others); Mon, 7 Mar 2022 05:17:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240427AbiCGKBB (ORCPT ); Mon, 7 Mar 2022 05:01:01 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABAF21EAD3; Mon, 7 Mar 2022 01:48:07 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 4C68960010; Mon, 7 Mar 2022 09:48:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 56163C340E9; Mon, 7 Mar 2022 09:48:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646646486; bh=z60zXuYXptNBGJ0tBVZp3+fhv8bqkROWAvgb8COEoY8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hPpGKoeChhaf4157b3zbDeGN6wRypAODuqgk+Rl3wm0UEFtZfCc/yXKkyTA281LXr 5D62YWNTHa4uCuwO2CmtS/YASjahU6Wpyh7S3/ndXpXqbXfdSW/mK7qpbd3d6C4PtT XqBGyN8iNIjZI39T1AxevRc+LaMmEvc9ACRWkLW4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Filipe Manana , Shinichiro Kawasaki , Sidong Yang , David Sterba Subject: [PATCH 5.15 257/262] btrfs: qgroup: fix deadlock between rescan worker and remove qgroup Date: Mon, 7 Mar 2022 10:20:01 +0100 Message-Id: <20220307091710.984548696@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220307091702.378509770@linuxfoundation.org> References: <20220307091702.378509770@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.6 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,T_SCC_BODY_TEXT_LINE 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: Sidong Yang commit d4aef1e122d8bbdc15ce3bd0bc813d6b44a7d63a upstream. The commit e804861bd4e6 ("btrfs: fix deadlock between quota disable and qgroup rescan worker") by Kawasaki resolves deadlock between quota disable and qgroup rescan worker. But also there is a deadlock case like it. It's about enabling or disabling quota and creating or removing qgroup. It can be reproduced in simple script below. for i in {1..100} do btrfs quota enable /mnt & btrfs qgroup create 1/0 /mnt & btrfs qgroup destroy 1/0 /mnt & btrfs quota disable /mnt & done Here's why the deadlock happens: 1) The quota rescan task is running. 2) Task A calls btrfs_quota_disable(), locks the qgroup_ioctl_lock mutex, and then calls btrfs_qgroup_wait_for_completion(), to wait for the quota rescan task to complete. 3) Task B calls btrfs_remove_qgroup() and it blocks when trying to lock the qgroup_ioctl_lock mutex, because it's being held by task A. At that point task B is holding a transaction handle for the current transaction. 4) The quota rescan task calls btrfs_commit_transaction(). This results in it waiting for all other tasks to release their handles on the transaction, but task B is blocked on the qgroup_ioctl_lock mutex while holding a handle on the transaction, and that mutex is being held by task A, which is waiting for the quota rescan task to complete, resulting in a deadlock between these 3 tasks. To resolve this issue, the thread disabling quota should unlock qgroup_ioctl_lock before waiting rescan completion. Move btrfs_qgroup_wait_for_completion() after unlock of qgroup_ioctl_lock. Fixes: e804861bd4e6 ("btrfs: fix deadlock between quota disable and qgroup rescan worker") CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Filipe Manana Reviewed-by: Shin'ichiro Kawasaki Signed-off-by: Sidong Yang Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/qgroup.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/fs/btrfs/qgroup.c +++ b/fs/btrfs/qgroup.c @@ -1197,13 +1197,20 @@ int btrfs_quota_disable(struct btrfs_fs_ goto out; /* + * Unlock the qgroup_ioctl_lock mutex before waiting for the rescan worker to + * complete. Otherwise we can deadlock because btrfs_remove_qgroup() needs + * to lock that mutex while holding a transaction handle and the rescan + * worker needs to commit a transaction. + */ + mutex_unlock(&fs_info->qgroup_ioctl_lock); + + /* * Request qgroup rescan worker to complete and wait for it. This wait * must be done before transaction start for quota disable since it may * deadlock with transaction by the qgroup rescan worker. */ clear_bit(BTRFS_FS_QUOTA_ENABLED, &fs_info->flags); btrfs_qgroup_wait_for_completion(fs_info, false); - mutex_unlock(&fs_info->qgroup_ioctl_lock); /* * 1 For the root item