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 C0CAE1E04B5; Wed, 6 Nov 2024 12:47:27 +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=1730897247; cv=none; b=l+OOiL65lOrMuqFCIOBC4YDhiKLqENmM34OMPn1Pjc0HcuDAZgdQ3Bx89PhJE4hrZXc5GMPt7J3YK2fm7u1vFilf2xuZU8kkhAZzabvBbI3JZsGDTppPuS7yeDnOGymdvDLVa3aMcv8Josfoo0bhnzQ7swqrw4wGtgV74flf/qs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730897247; c=relaxed/simple; bh=Bjh/LNNMCXmrAGXSw9yMtn/Ux8Cgcg26Ftmhvq5nAyw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=haD/V2NX/qxEP/8QNJuePqENSq/Y9p8TSeuSYaEuc5Ck44VspJRQfg3f4wncMBxiTINjps/A9W9woK/PriDfzlajsQs1kLpyC7FyUHXXci+d3nvMU/2qzpny/4ZAK3iIUjpRz+eSQMGxOxOGAgFQv8pJb4xgWqe78dUyyxYGXBg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=QT2gtJhI; 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="QT2gtJhI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 423D1C4CED3; Wed, 6 Nov 2024 12:47:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1730897247; bh=Bjh/LNNMCXmrAGXSw9yMtn/Ux8Cgcg26Ftmhvq5nAyw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QT2gtJhIBvK4LzxDU1HWkdETsHww5IjJUJMk1h+G24SNDhZqHmBfU6FNeHW0yTvjy 229ZhRU2PhquLd2xEPiSKcw7o99/7P2QIjVUo04abQquGOStdTqtQgUNOz5no14iph JPX44p9wPIevE7l6wVEQrarh6jA4EATtYHEk7JsY= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Ryusuke Konishi , syzbot+9ef37ac20608f4836256@syzkaller.appspotmail.com, Andrew Morton Subject: [PATCH 6.1 079/126] nilfs2: fix potential deadlock with newly created symlinks Date: Wed, 6 Nov 2024 13:04:40 +0100 Message-ID: <20241106120308.216554564@linuxfoundation.org> X-Mailer: git-send-email 2.47.0 In-Reply-To: <20241106120306.038154857@linuxfoundation.org> References: <20241106120306.038154857@linuxfoundation.org> User-Agent: quilt/0.67 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.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ryusuke Konishi commit b3a033e3ecd3471248d474ef263aadc0059e516a upstream. Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints. Link: https://lkml.kernel.org/r/20241020050003.4308-1-konishi.ryusuke@gmail.com Fixes: 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem") Signed-off-by: Ryusuke Konishi Reported-by: syzbot+9ef37ac20608f4836256@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9ef37ac20608f4836256 Tested-by: syzbot+9ef37ac20608f4836256@syzkaller.appspotmail.com Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- fs/nilfs2/namei.c | 3 +++ 1 file changed, 3 insertions(+) --- a/fs/nilfs2/namei.c +++ b/fs/nilfs2/namei.c @@ -157,6 +157,9 @@ static int nilfs_symlink(struct user_nam /* slow symlink */ inode->i_op = &nilfs_symlink_inode_operations; inode_nohighmem(inode); + mapping_set_gfp_mask(inode->i_mapping, + mapping_gfp_constraint(inode->i_mapping, + ~__GFP_FS)); inode->i_mapping->a_ops = &nilfs_aops; err = page_symlink(inode, symname, l); if (err)