From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 97113280037; Tue, 27 May 2025 17:57:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748368621; cv=none; b=HXfa0BkH2tQaK5g2X251zKlOuWq+VW5n42Bonj9I4oUO1IfzlPBzlRhE1MzoZ6djtVfswC/AgPvBopw+MSIbexeY9QaP3ilPbfdmpgHozpTdOsDddDoF59jxjJeTvQ/BP7MBrOTx+wzTzaOHfUUQ/+Clt+Mv90PNMNHhVHJza7w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748368621; c=relaxed/simple; bh=fIS8GoVyO/Kj0xAZO9SwznM/HnYyteJ6dQFA4DggeiQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BL+sqQnReFIxr3eiBvBzYcO5Z5ZDC9Sue4yAiLGEOZvE56sZJl91RzOWK/iChqlZwnnRcJigyaweDDmTKNKo1gs7joqpHuqr3B2MB0KbZabGLzmgSN7DW4c8LOlnmOPw+5YQV8tNDPUR4arVYPEIw/aKET/03htO+q8iynUscuY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=1zL5yS/g; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="1zL5yS/g" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BEEA9C4CEE9; Tue, 27 May 2025 17:57:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1748368621; bh=fIS8GoVyO/Kj0xAZO9SwznM/HnYyteJ6dQFA4DggeiQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1zL5yS/gGioeyjTECLiD6SUFhp5w554rpHEQwKUmybrfZ3gFPMpidF9S1UPOrNoN5 F1fWnA0XGlAdE0VjHkHT2NlNCKL/WVKl982XVQZchbn6Fbq7DzF43jT2TWqbQYH98c nWG3Yv3CVtZUAMNDoi8bLJdK8zJQQfteY8x3roxU= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Ryusuke Konishi , syzbot+00f7f5b884b117ee6773@syzkaller.appspotmail.com, syzbot+f30591e72bfc24d4715b@syzkaller.appspotmail.com, Andrew Morton Subject: [PATCH 6.14 765/783] nilfs2: fix deadlock warnings caused by lock dependency in init_nilfs() Date: Tue, 27 May 2025 18:29:22 +0200 Message-ID: <20250527162544.289471926@linuxfoundation.org> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250527162513.035720581@linuxfoundation.org> References: <20250527162513.035720581@linuxfoundation.org> User-Agent: quilt/0.68 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ryusuke Konishi commit fb881cd7604536b17a1927fb0533f9a6982ffcc5 upstream. After commit c0e473a0d226 ("block: fix race between set_blocksize and read paths") was merged, set_blocksize() called by sb_set_blocksize() now locks the inode of the backing device file. As a result of this change, syzbot started reporting deadlock warnings due to a circular dependency involving the semaphore "ns_sem" of the nilfs object, the inode lock of the backing device file, and the locks that this inode lock is transitively dependent on. This is caused by a new lock dependency added by the above change, since init_nilfs() calls sb_set_blocksize() in the lock section of "ns_sem". However, these warnings are false positives because init_nilfs() is called in the early stage of the mount operation and the filesystem has not yet started. The reason why "ns_sem" is locked in init_nilfs() was to avoid a race condition in nilfs_fill_super() caused by sharing a nilfs object among multiple filesystem instances (super block structures) in the early implementation. However, nilfs objects and super block structures have long ago become one-to-one, and there is no longer any need to use the semaphore there. So, fix this issue by removing the use of the semaphore "ns_sem" in init_nilfs(). Link: https://lkml.kernel.org/r/20250503053327.12294-1-konishi.ryusuke@gmail.com Fixes: c0e473a0d226 ("block: fix race between set_blocksize and read paths") Signed-off-by: Ryusuke Konishi Reported-by: syzbot+00f7f5b884b117ee6773@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=00f7f5b884b117ee6773 Tested-by: syzbot+00f7f5b884b117ee6773@syzkaller.appspotmail.com Reported-by: syzbot+f30591e72bfc24d4715b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f30591e72bfc24d4715b Tested-by: syzbot+f30591e72bfc24d4715b@syzkaller.appspotmail.com> Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- fs/nilfs2/the_nilfs.c | 3 --- 1 file changed, 3 deletions(-) --- a/fs/nilfs2/the_nilfs.c +++ b/fs/nilfs2/the_nilfs.c @@ -705,8 +705,6 @@ int init_nilfs(struct the_nilfs *nilfs, int blocksize; int err; - down_write(&nilfs->ns_sem); - blocksize = sb_min_blocksize(sb, NILFS_MIN_BLOCK_SIZE); if (!blocksize) { nilfs_err(sb, "unable to set blocksize"); @@ -779,7 +777,6 @@ int init_nilfs(struct the_nilfs *nilfs, set_nilfs_init(nilfs); err = 0; out: - up_write(&nilfs->ns_sem); return err; failed_sbh: