Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp341318pxu; Fri, 11 Dec 2020 03:46:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJzoSkMeYLn8Rwx+EbcYSh2jDNuWJpuw8Hkd/QN7/Eo5GnMhLdDpnB82g1siBBhhL/h/gFrO X-Received: by 2002:a17:906:7fcf:: with SMTP id r15mr11132780ejs.79.1607687173699; Fri, 11 Dec 2020 03:46:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607687173; cv=none; d=google.com; s=arc-20160816; b=k7fQ9fcFQA6ff4xbjrRhrn8+o/7Nnv+htBcrkdYnLPaw9y/Uv9+wLdpDDXRd57x1FO BOUjDIpdLNFwkkXBQF6SXnfkH/GjlmWLZHTL4ReHcDpRr2HKJ1uI/9R4joke+7WNyYdG v4wN81aYvT1WSxCf3sM5pKfhcWtEWjnjU66nd9fSiSNX3wsq8/R8eUKRCNh8lgQfQH5V j0vrSr7WPUEBqX2Rn+tiNJwco2V1Cl0XF3t2fHHkdqVvTfUFOZNjJfi8WfCmv38FqxBT 99OZX3UrvsK+69ytzOyGqNbCzbjF6bI7AopaIBiMqdWM95i0TALI0XzFenZzvVAAdd9z dprg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:dkim-signature:date; bh=69pwxsD4xODFw7vV2/mAwWGDBip4up7ONCYhkt0O1JY=; b=wWleYEyekZ4IbzWuDQbZOF0aYVJ7F+iJCxd9Z3GmCSa8G0BTUSJobRvaEXMNNpngx8 DlQkSxN68lyY6VgKLDsav5A/zhF4mBm/1oyTq62RR3Fxne++stOnoE+rtEgG91O1pgSE 4+/d+WkIMZHN6uE6FK1uiAf5pe3m5MZpeozjXpm4WPqMAjhr5/wFEQrlqWYFglYVAKfv 6uzR33FW5jFLAYdW96j0xs/+JYbCKb6hJKz1/V5bRSilGP+Obq0xSTv8/aDUg7crbxaQ smt+vapAlKoyXVJ2DF7Z7SYygypYN8AFCC5HaPE/OQliC9PiQbVD48ui9fmZGYElXzIq eNTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=CeGmuBGm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s18si5011763eji.422.2020.12.11.03.45.51; Fri, 11 Dec 2020 03:46:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=CeGmuBGm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2395215AbgLKDt2 (ORCPT + 99 others); Thu, 10 Dec 2020 22:49:28 -0500 Received: from mail.kernel.org ([198.145.29.99]:59276 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392246AbgLKDtL (ORCPT ); Thu, 10 Dec 2020 22:49:11 -0500 Date: Thu, 10 Dec 2020 19:48:28 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1607658510; bh=Br3yuvlVdobQPxlXHKs4wQB/cIvXf86koFgZ9Pt0j/I=; h=From:To:Cc:Subject:References:In-Reply-To:From; b=CeGmuBGmrNQ0UgfHF4HrDRwl+Z2xompa+zzA01sr1fHrJH6pXEjy0OcNodFXvaQDs nBAsfbqsvdSysp5a5L1nXGMxK0fowJ2oWqCF0VPlXFUKYHwDijXED02ekeHFhFwsHM japuICgQFbL95/FOmfFkpu6OJyKASc35G1hpzX9X8gIXUsNBuY9+7oH+WMltQMh4Jy wJsMHwVAb3Wl3bWR0abtoXa8Wn1xltBwUxS6qVvDbDj3JoRynjZ5BvWVVZzgQjH4pt /ePYcokVHvuGgWTsVOBXIZAL9emokM26HL7LVZU9gTbqm96ngwbLmxpG5LdS6eo/1w dcGcOYcSnctKQ== From: Eric Biggers To: Sergey Senozhatsky Cc: Greg Kroah-Hartman , Jaegeuk Kim , "Theodore Y. Ts'o" , Suleiman Souhlal , linux-fscrypt@vger.kernel.org, stable@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [stable] ext4 fscrypt_get_encryption_info() circular locking dependency Message-ID: References: <20201211033657.GE1667627@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201211033657.GE1667627@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 11, 2020 at 12:36:57PM +0900, Sergey Senozhatsky wrote: > Hi, > > I got the following lockdep splat the other day, while running some > tests on 4.19. I didn't test other stable kernels, but it seems that > 5.4 should also have similar problem. > > As far as I can tell, ext4_dir_open() has been removed quite recently: > https://www.mail-archive.com/linux-f2fs-devel@lists.sourceforge.net/msg18727.html > > Eric, Ted, Jaegeuk, how difficult would it be to remove ext4_dir_open() > from the stable kernels? (I'm interested in ext4 in particular, I > understand that other filesystems may also need similar patches) > > > > [ 133.454721] kswapd0/79 is trying to acquire lock: > [ 133.454724] 00000000a815a55f (jbd2_handle){++++}, at: start_this_handle+0x1f9/0x859 > [ 133.454730] > but task is already holding lock: > [ 133.454731] 00000000106bd5a3 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x5/0x2f > [ 133.454736] > which lock already depends on the new lock. > > [ 133.454739] > the existing dependency chain (in reverse order) is: > [ 133.454740] > -> #2 (fs_reclaim){+.+.}: > [ 133.454745] kmem_cache_alloc_trace+0x44/0x28b > [ 133.454748] mempool_create_node+0x46/0x92 > [ 133.454750] fscrypt_initialize+0xa0/0xbf > [ 133.454752] fscrypt_get_encryption_info+0xa4/0x774 > [ 133.454754] ext4_dir_open+0x1b/0x2d > [ 133.454757] do_dentry_open+0x144/0x36d > [ 133.454759] path_openat+0x2d7/0x156d > [ 133.454762] do_filp_open+0x97/0x13e > [ 133.454764] do_sys_open+0x128/0x3a3 > [ 133.454766] do_syscall_64+0x6f/0x22a > [ 133.454769] entry_SYSCALL_64_after_hwframe+0x49/0xbe > [ 133.454771] > -> #1 (fscrypt_init_mutex){+.+.}: > [ 133.454774] mutex_lock_nested+0x20/0x26 > [ 133.454776] fscrypt_initialize+0x20/0xbf > [ 133.454778] fscrypt_get_encryption_info+0xa4/0x774 > [ 133.454780] fscrypt_inherit_context+0xbe/0xe6 > [ 133.454782] __ext4_new_inode+0x11ee/0x1631 > [ 133.454785] ext4_mkdir+0x112/0x416 > [ 133.454787] vfs_mkdir2+0x135/0x1c6 > [ 133.454789] do_mkdirat+0xc3/0x138 > [ 133.454791] do_syscall_64+0x6f/0x22a > [ 133.454793] entry_SYSCALL_64_after_hwframe+0x49/0xbe > [ 133.454795] > -> #0 (jbd2_handle){++++}: > [ 133.454798] start_this_handle+0x21c/0x859 > [ 133.454800] jbd2__journal_start+0xa2/0x282 > [ 133.454802] ext4_release_dquot+0x58/0x93 > [ 133.454804] dqput+0x196/0x1ec > [ 133.454806] __dquot_drop+0x8d/0xb2 > [ 133.454809] ext4_clear_inode+0x22/0x8c > [ 133.454811] ext4_evict_inode+0x127/0x662 > [ 133.454813] evict+0xc0/0x241 > [ 133.454816] dispose_list+0x36/0x54 > [ 133.454818] prune_icache_sb+0x56/0x76 > [ 133.454820] super_cache_scan+0x13a/0x19c > [ 133.454822] shrink_slab+0x39a/0x572 > [ 133.454824] shrink_node+0x3f8/0x63b > [ 133.454826] balance_pgdat+0x1bd/0x326 > [ 133.454828] kswapd+0x2ad/0x510 > [ 133.454831] kthread+0x14d/0x155 > [ 133.454833] ret_from_fork+0x24/0x50 > [ 133.454834] > other info that might help us debug this: > > [ 133.454836] Chain exists of: > jbd2_handle --> fscrypt_init_mutex --> fs_reclaim > > [ 133.454840] Possible unsafe locking scenario: > > [ 133.454841] CPU0 CPU1 > [ 133.454843] ---- ---- > [ 133.454844] lock(fs_reclaim); > [ 133.454846] lock(fscrypt_init_mutex); > [ 133.454848] lock(fs_reclaim); > [ 133.454850] lock(jbd2_handle); > [ 133.454851] This actually got fixed by the patch series https://lkml.kernel.org/linux-fscrypt/20200913083620.170627-1-ebiggers@kernel.org/ which went into 5.10. The more recent patch to remove ext4_dir_open() isn't related. It's a hard patch series to backport. Backporting it to 5.4 would be somewhat feasible, while 4.19 would be very difficult as there have been a lot of other fscrypt commits which would heavily conflict with cherry-picks. How interested are you in having this fixed? Did you encounter an actual deadlock or just the lockdep report? - Eric