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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE autolearn=unavailable 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 1653BC47E4B for ; Thu, 15 Jul 2021 04:27:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BE22B613A9 for ; Thu, 15 Jul 2021 04:27:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BE22B613A9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1C83A6B0152; Thu, 15 Jul 2021 00:27:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 19F186B0154; Thu, 15 Jul 2021 00:27:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 067A36B0155; Thu, 15 Jul 2021 00:27:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0076.hostedemail.com [216.40.44.76]) by kanga.kvack.org (Postfix) with ESMTP id D787E6B0152 for ; Thu, 15 Jul 2021 00:27:10 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id CAF321F20E for ; Thu, 15 Jul 2021 04:27:09 +0000 (UTC) X-FDA: 78363537378.36.D111D4F Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf11.hostedemail.com (Postfix) with ESMTP id 69EC0F000225 for ; Thu, 15 Jul 2021 04:27:09 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 70E8C61380; Thu, 15 Jul 2021 04:27:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1626323228; bh=H2vlNlo8faCnYTwf4DwHdOxymTkwkkSjiStHkHZLw/o=; h=Date:From:To:Subject:In-Reply-To:From; b=OienGAGnhvQSsUoH9AsH0VabDDzH1GsXLPHkGRaycrbeuxczgKb4VYcUBxWT45V7N jAQ6xJwkzI+luG3p16VTXBisE2ADQtHexdBnJ+6KTFuWDCD02ffYYBqNLhyqf1vg80 Fw8mx19DGKCZuwLZ3Y58xsKc8KJJtCg6VeUg8eXM= Date: Wed, 14 Jul 2021 21:27:08 -0700 From: Andrew Morton To: akpm@linux-foundation.org, desmondcheongzx@gmail.com, gregkh@linuxfoundation.org, gustavoars@kernel.org, linux-mm@kvack.org, mm-commits@vger.kernel.org, skhan@linuxfoundation.org, slava@dubeyko.com, torvalds@linux-foundation.org, viro@zeniv.linux.org.uk Subject: [patch 12/13] hfs: add lock nesting notation to hfs_find_init Message-ID: <20210715042708.eP0VysJim%akpm@linux-foundation.org> In-Reply-To: <20210714212609.fad116e584ba1194981a6294@linux-foundation.org> User-Agent: s-nail v14.8.16 Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=OienGAGn; spf=pass (imf11.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam02 X-Stat-Signature: oaet35x4mbmgyy7rxhqonkeenydr3tc9 X-Rspamd-Queue-Id: 69EC0F000225 X-HE-Tag: 1626323229-736054 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Desmond Cheong Zhi Xi Subject: hfs: add lock nesting notation to hfs_find_init Syzbot reports a possible recursive lock: https://syzkaller.appspot.com/bug?id=f007ef1d7a31a469e3be7aeb0fde0769b18585db This happens due to missing lock nesting information. From the logs, we see that a call to hfs_fill_super is made to mount the hfs filesystem. While searching for the root inode, the lock on the catalog btree is grabbed. Then, when the parent of the root isn't found, a call to __hfs_bnode_create is made to create the parent of the root. This eventually leads to a call to hfs_ext_read_extent which grabs a lock on the extents btree. Since the order of locking is catalog btree -> extents btree, this lock hierarchy does not lead to a deadlock. To tell lockdep that this locking is safe, we add nesting notation to distinguish between catalog btrees, extents btrees, and attributes btrees (for HFS+). This has already been done in hfsplus. Link: https://lkml.kernel.org/r/20210701030756.58760-4-desmondcheongzx@gmail.com Signed-off-by: Desmond Cheong Zhi Xi Reported-by: syzbot+b718ec84a87b7e73ade4@syzkaller.appspotmail.com Tested-by: syzbot+b718ec84a87b7e73ade4@syzkaller.appspotmail.com Reviewed-by: Viacheslav Dubeyko Cc: Al Viro Cc: Greg Kroah-Hartman Cc: Gustavo A. R. Silva Cc: Shuah Khan Signed-off-by: Andrew Morton --- fs/hfs/bfind.c | 14 +++++++++++++- fs/hfs/btree.h | 7 +++++++ 2 files changed, 20 insertions(+), 1 deletion(-) --- a/fs/hfs/bfind.c~hfs-add-lock-nesting-notation-to-hfs_find_init +++ a/fs/hfs/bfind.c @@ -25,7 +25,19 @@ int hfs_find_init(struct hfs_btree *tree fd->key = ptr + tree->max_key_len + 2; hfs_dbg(BNODE_REFS, "find_init: %d (%p)\n", tree->cnid, __builtin_return_address(0)); - mutex_lock(&tree->tree_lock); + switch (tree->cnid) { + case HFS_CAT_CNID: + mutex_lock_nested(&tree->tree_lock, CATALOG_BTREE_MUTEX); + break; + case HFS_EXT_CNID: + mutex_lock_nested(&tree->tree_lock, EXTENTS_BTREE_MUTEX); + break; + case HFS_ATTR_CNID: + mutex_lock_nested(&tree->tree_lock, ATTR_BTREE_MUTEX); + break; + default: + return -EINVAL; + } return 0; } --- a/fs/hfs/btree.h~hfs-add-lock-nesting-notation-to-hfs_find_init +++ a/fs/hfs/btree.h @@ -13,6 +13,13 @@ typedef int (*btree_keycmp)(const btree_ #define NODE_HASH_SIZE 256 +/* B-tree mutex nested subclasses */ +enum hfs_btree_mutex_classes { + CATALOG_BTREE_MUTEX, + EXTENTS_BTREE_MUTEX, + ATTR_BTREE_MUTEX, +}; + /* A HFS BTree held in memory */ struct hfs_btree { struct super_block *sb; _