From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A4AAEC43387 for ; Tue, 15 Jan 2019 15:42:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6A43320866 for ; Tue, 15 Jan 2019 15:42:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1547566927; bh=RsmFOKAB+xd24sGsh7w9Mpk3A0HyMol1m1Lve+iFQmM=; h=Subject:To:Cc:From:Date:List-ID:From; b=e+M3Wv6UusUP2X6kxr8GdGOE9CegiGNoDfHHTtU2Hek0tlgemGtQZ9c83uJtxTtTi jjPNQab2Zd+UQB5355TpCaYfgSsQW9pKHBx9/WiXbqZhrmgxHXi6DofDNxs6Ay/RM3 rcWdCvTbpv/yw1wCB6taBTLF725em3rsHW4s/OwA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728060AbfAOPmH (ORCPT ); Tue, 15 Jan 2019 10:42:07 -0500 Received: from new3-smtp.messagingengine.com ([66.111.4.229]:34845 "EHLO new3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729710AbfAOPmG (ORCPT ); Tue, 15 Jan 2019 10:42:06 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 4B3DE939; Tue, 15 Jan 2019 10:42:05 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 15 Jan 2019 10:42:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Hnm8Rg p9QcQ+awmULIVHRqe39bms95t+44yB55KqQug=; b=NKISYxLd6c6PILyhfhDUaZ rKEDMQyp6fOeogCQAT8Oj+H+y59bzxA16uwgtQ54IrPtVtjwQMPWlI3eaO4SiC78 Vx4cFchfb4MoKj8BOUg1pxb8IQJNW8CRmBTo9jAvZrBrTGk4LNWSXI3G0Uh7t7E7 OSKBz8XKETy+aSNWG1LVqkob3+bm7qvHnjzt9uVMHxdvMwKOJx8KNEibejYvE3ra Dr+7Jc8kGoW+CCj1MJGoO/pEXLgWqsIpuuU+Z2BfQRnCHpuFnhpmHWdUq8SFKS3v CDq8hhGms58oLNvIVAm0B1f5vQIx52JeWLKMHtZxcZiCULTooFeJ2/lzMmUbu/2A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgeefgdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucgoufhprghmkfhpucdlfedttddmnecujfgurhepuffvhfffkfggtgfgsehtkeertd dttdflnecuhfhrohhmpeeoghhrvghgkhhhsehlihhnuhigfhhouhhnuggrthhiohhnrdho rhhgqeenucfkphepkeefrdekiedrkeelrddutdejnecurfgrrhgrmhepmhgrihhlfhhroh hmpehgrhgvgheskhhrohgrhhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from localhost (5356596b.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) by mail.messagingengine.com (Postfix) with ESMTPA id AA73C10281; Tue, 15 Jan 2019 10:42:04 -0500 (EST) Subject: FAILED: patch "[PATCH] Btrfs: fix deadlock when enabling quotas due to concurrent" failed to apply to 4.4-stable tree To: fdmanana@suse.com, dsterba@suse.com Cc: From: Date: Tue, 15 Jan 2019 16:42:03 +0100 Message-ID: <15475669232124@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 9a6f209e36500efac51528132a3e3083586eda5f Mon Sep 17 00:00:00 2001 From: Filipe Manana Date: Mon, 19 Nov 2018 14:15:36 +0000 Subject: [PATCH] Btrfs: fix deadlock when enabling quotas due to concurrent snapshot creation If the quota enable and snapshot creation ioctls are called concurrently we can get into a deadlock where the task enabling quotas will deadlock on the fs_info->qgroup_ioctl_lock mutex because it attempts to lock it twice, or the task creating a snapshot tries to commit the transaction while the task enabling quota waits for the former task to commit the transaction while holding the mutex. The following time diagrams show how both cases happen. First scenario: CPU 0 CPU 1 btrfs_ioctl() btrfs_ioctl_quota_ctl() btrfs_quota_enable() mutex_lock(fs_info->qgroup_ioctl_lock) btrfs_start_transaction() btrfs_ioctl() btrfs_ioctl_snap_create_v2 create_snapshot() --> adds snapshot to the list pending_snapshots of the current transaction btrfs_commit_transaction() create_pending_snapshots() create_pending_snapshot() qgroup_account_snapshot() btrfs_qgroup_inherit() mutex_lock(fs_info->qgroup_ioctl_lock) --> deadlock, mutex already locked by this task at btrfs_quota_enable() Second scenario: CPU 0 CPU 1 btrfs_ioctl() btrfs_ioctl_quota_ctl() btrfs_quota_enable() mutex_lock(fs_info->qgroup_ioctl_lock) btrfs_start_transaction() btrfs_ioctl() btrfs_ioctl_snap_create_v2 create_snapshot() --> adds snapshot to the list pending_snapshots of the current transaction btrfs_commit_transaction() --> waits for task at CPU 0 to release its transaction handle btrfs_commit_transaction() --> sees another task started the transaction commit first --> releases its transaction handle --> waits for the transaction commit to be completed by the task at CPU 1 create_pending_snapshot() qgroup_account_snapshot() btrfs_qgroup_inherit() mutex_lock(fs_info->qgroup_ioctl_lock) --> deadlock, task at CPU 0 has the mutex locked but it is waiting for us to finish the transaction commit So fix this by setting the quota enabled flag in fs_info after committing the transaction at btrfs_quota_enable(). This ends up serializing quota enable and snapshot creation as if the snapshot creation happened just before the quota enable request. The quota rescan task, scheduled after committing the transaction in btrfs_quote_enable(), will do the accounting. Fixes: 6426c7ad697d ("btrfs: qgroup: Fix qgroup accounting when creating snapshot") Signed-off-by: Filipe Manana Signed-off-by: David Sterba diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c index b53d2e7b938d..2272419ade7e 100644 --- a/fs/btrfs/qgroup.c +++ b/fs/btrfs/qgroup.c @@ -1013,16 +1013,22 @@ int btrfs_quota_enable(struct btrfs_fs_info *fs_info) btrfs_abort_transaction(trans, ret); goto out_free_path; } - spin_lock(&fs_info->qgroup_lock); - fs_info->quota_root = quota_root; - set_bit(BTRFS_FS_QUOTA_ENABLED, &fs_info->flags); - spin_unlock(&fs_info->qgroup_lock); ret = btrfs_commit_transaction(trans); trans = NULL; if (ret) goto out_free_path; + /* + * Set quota enabled flag after committing the transaction, to avoid + * deadlocks on fs_info->qgroup_ioctl_lock with concurrent snapshot + * creation. + */ + spin_lock(&fs_info->qgroup_lock); + fs_info->quota_root = quota_root; + set_bit(BTRFS_FS_QUOTA_ENABLED, &fs_info->flags); + spin_unlock(&fs_info->qgroup_lock); + ret = qgroup_rescan_init(fs_info, 0, 1); if (!ret) { qgroup_rescan_zero_tracking(fs_info);