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 Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 25A5AEF36F7 for ; Mon, 9 Mar 2026 07:37:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type:Cc: Reply-To:From:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:In-Reply-To:References:To:MIME-Version:Date: Message-ID:Sender:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=8GpCDzWJSqBy7kFQKUTLvIYd36Vjo3fYgixfa91eL9o=; b=FA2XC4VMcrU7CMJJSW0Ivl2Qsm ye4sWMNAgs9/N9rNM/244eb7aJNzpef2I8nehnyBB7mYe6Gq9vrNvTw5GylDTWG1swlzdFBv22m1/ sJ/5i0x8WyLeVp+Qh67TyYaHTacGBmhwhqcwVOO26FJqT+tOUftI4YWNQLwGVuwdTwnA=; Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1vzVAn-0000Pn-9a; Mon, 09 Mar 2026 07:37:05 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1vzVAm-0000Ph-EE for linux-f2fs-devel@lists.sourceforge.net; Mon, 09 Mar 2026 07:37:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: From:References:To:Subject:Cc:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=RP0CU9O060axuwEXrDlcUhLJJz62JKC1M2c36dcEVPI=; b=OTU0RMrjIFBmp2aV9J6SHZPWbs 2HL6jLPRg44VGV0vakJl4YmbkLXfc64BOlvkKDRJaF5IEv7mGmwj4RaGd2iGa9W6MJREepTqGeYk+ ZkpMRLtpcI7T7RR+fiF0FTgUBq+X5jEsS2UFEMSV6HW77VH5Ph35m8xfiGB2jPty4WF0=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:To: Subject:Cc:MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=RP0CU9O060axuwEXrDlcUhLJJz62JKC1M2c36dcEVPI=; b=BemH44Nym9q04lZ/RG7Tr6fdao 7g2h+UsKlzJsPWcp2NUwfJPX1n8+YuGQawU3yzX0U9aBg93vXVL8dLkLn9Uu36aledZWX5ve+0qic BKvKSzEB0QL+1GXNWy9anajzVLVDT9+hVhMVTEBVut1BY1M48RuBOazYNq6MvZ+jqqpA=; Received: from tor.source.kernel.org ([172.105.4.254]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1vzVAl-0005yj-ST for linux-f2fs-devel@lists.sourceforge.net; Mon, 09 Mar 2026 07:37:04 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 3572160131; Mon, 9 Mar 2026 07:36:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BBD3DC2BC87; Mon, 9 Mar 2026 07:36:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773041812; bh=531aVQvYSEq8d+c9Tu0j7xygp7hVakIX0YFV+fxGR3A=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=I5X/0uW2EIefYnoSvUMSeBHxhKMUNHPl8ZqmVUPY2C9DxZT5E26UEcA/KRUiP6v55 zdKHYvg0APZ3p73lOm6BmSoj/W9BqlKXF8tl0I4pVwE9V7XgML6xMWX0vv2M9OcBIv o7ubaql5DptDgTYtSTuV8fu99F3onjTOrps29dgxPvJB6kAUctlY5VhWaHlgAwr2PC Yhrv7ocy06anYPcpxcqDjRk9OLjpP2KYqjZPK5O0w0fov5Vyu7GPpco0jxBl2EBAvJ an+QdExu72gVb+2r1cIn+4ghjsgzYewfwwJlQrWZdUwmp7ba5NZwZ81xDVQ76RqE/1 FUSKDkx1cf1iw== Message-ID: Date: Mon, 9 Mar 2026 15:36:48 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Jaegeuk Kim References: <2026022422-robotics-conform-9b68@gregkh> Content-Language: en-US In-Reply-To: <2026022422-robotics-conform-9b68@gregkh> X-Headers-End: 1vzVAl-0005yj-ST Subject: Re: [f2fs-dev] [PATCH] f2fs: fix potential deadlock in f2fs_convert_inline_inode X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Chao Yu via Linux-f2fs-devel Reply-To: Chao Yu Cc: Greg Kroah-Hartman , stable , linux-f2fs-devel@lists.sourceforge.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On 2/24/26 09:04, Greg Kroah-Hartman wrote: > f2fs_convert_inline_inode() holds the page lock of the inline data page > and then calls f2fs_lock_op(), which acquires cp_rwsem in read mode. > At the same time, f2fs_write_checkpoint() can acquire cp_rwsem in write > mode and then will wait for page locks, like during > f2fs_write_node_pages() or data flushing, leading to a deadlock. - f2fs_convert_inline_inode - f2fs_write_checkpoint() - f2fs_grab_cache_folio page #0 - block_operations - f2fs_lock_all - f2fs_lock_op - f2fs_sync_node_pages - flush_inline_data - f2fs_filemap_get_folio page #0 It seems true, although I didn't hit such deadlock. To Jaegeuk, what do you think? > > Fix this by acquiring the lock_op before locking the page. This ensures > the correct lock ordering, op before page, and avoids the deadlock. > > Cc: Jaegeuk Kim > Cc: Chao Yu > Cc: stable > Assisted-by: gkh_clanker_2000 > Signed-off-by: Greg Kroah-Hartman > --- > > This issue was found by running a tool to compare a past kernel CVE to > try to find any potential places in the existing codebase that was > missed with the original fix. I do not know if this patch or text > really is correct, but the code paths seems sane. > > Note that the majority of the changelog text came from an untrusted and > experimental LLM model that is known for making crap up. So it might be > totally lying here, and if so, I am very sorry for wasting anyone's time > and I'll just go back to running this on code that I actually understand > and know how to verify myself, but I figured it was worth at least > asking you all about it. > > fs/f2fs/inline.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c > index 0a1052d5ee62..98bc920a4f35 100644 > --- a/fs/f2fs/inline.c > +++ b/fs/f2fs/inline.c > @@ -232,12 +232,14 @@ int f2fs_convert_inline_inode(struct inode *inode) > if (err) > return err; > > - folio = f2fs_grab_cache_folio(inode->i_mapping, 0, false); > - if (IS_ERR(folio)) > - return PTR_ERR(folio); > - > f2fs_lock_op(sbi, &lc); > > + folio = f2fs_grab_cache_folio(inode->i_mapping, 0, false); > + if (IS_ERR(folio)) { > + f2fs_unlock_op(sbi, &lc); > + return PTR_ERR(folio); > + } > + It will be better to adjust the unlock order in between cp_rwsem and folio lock? out: f2fs_folio_put(folio, true); f2fs_unlock_op(sbi, &lc); Thanks, > ifolio = f2fs_get_inode_folio(sbi, inode->i_ino); > if (IS_ERR(ifolio)) { > err = PTR_ERR(ifolio); _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel