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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 21134C433F5 for ; Fri, 19 Nov 2021 08:45:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9DF4A61AD2 for ; Fri, 19 Nov 2021 08:45:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9DF4A61AD2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 154736B006C; Fri, 19 Nov 2021 03:44:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 106916B0071; Fri, 19 Nov 2021 03:44:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F35FD6B0073; Fri, 19 Nov 2021 03:44:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0057.hostedemail.com [216.40.44.57]) by kanga.kvack.org (Postfix) with ESMTP id E60D86B006C for ; Fri, 19 Nov 2021 03:44:58 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A938B876E1 for ; Fri, 19 Nov 2021 08:44:48 +0000 (UTC) X-FDA: 78825044256.06.2F03093 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf23.hostedemail.com (Postfix) with ESMTP id 00BC290000A5 for ; Fri, 19 Nov 2021 08:44:45 +0000 (UTC) Date: Fri, 19 Nov 2021 09:44:44 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1637311486; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=BtHRJz56fjI816Vn1TPP0n0DadX6sQ2/aRWzMEJXVjw=; b=t3jQQmhfM/qu/MU4bcBhDzuuO1HGUMNsWHaYjtinuUpYQRwrQWhVJwPE9DYvc5QyX1W7wb ZTQXy7VebihBaJdpVYJpziXqsdXaTYN+5D6X7I3DEfyQ2xLURRYWgcF0+k31K4cbZCtK0+ 7Ie2cFn57UkRIXsRsWFqYADUHrRKmeNv4wtIGIXBgFKYTWy3YYfYN0Rna7fNJz/A3AeP7e ElR6zmOBtjyGpxN4xsxUh6Lwe76AMh6J4LQ1C9wy42yFNJoadfN6JYh7G1qUKhznby2DBc xcKNqGY80QV05gzmlvBHx9x8KwSIW8y9A20PZ0g7EwivQZoqQ0EIzViWB+gdNQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1637311486; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=BtHRJz56fjI816Vn1TPP0n0DadX6sQ2/aRWzMEJXVjw=; b=M/LNHYHldptZ5tkswNllkxsKiZnKTGFvZ5n2szjHjkBIOEVaZuo8J9ssY2oe2Jkfn4XiSh 2ERLWSDxpWsBcLAA== From: Sebastian Andrzej Siewior To: linux-xfs@vger.kernel.org, linux-mm@kvack.org Cc: "Darrick J. Wong" , Thomas Gleixner , Andrew Morton , Dave Chinner Subject: [LOCKDEP] Circular locking dependency detected, fs_reclaim vs xfs_nondir_ilock_class Message-ID: <20211119084444.ykmkdogsjdj3vtbi@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 00BC290000A5 Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=t3jQQmhf; dkim=pass header.d=linutronix.de header.s=2020e header.b="M/LNHYHl"; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf23.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de X-Stat-Signature: rp1ut3yqcnwp7xs77ha856xzcmfngxs4 X-HE-Tag: 1637311485-341685 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: Hi, left my box unattended for a while and lockdep reported this: | ====================================================== | WARNING: possible circular locking dependency detected | 5.16.0-rc1+ #12 Not tainted | ------------------------------------------------------ | kswapd1/510 is trying to acquire lock: | ffff88800c98ac70 (&xfs_nondir_ilock_class){++++}-{3:3}, at: xfs_icwalk_ag+0x365/0x810 | | but task is already holding lock: | ffffffff82a76d60 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x4c4/0x5b0 | | which lock already depends on the new lock. | | | the existing dependency chain (in reverse order) is: | | -> #1 (fs_reclaim){+.+.}-{0:0}: | fs_reclaim_acquire+0xa1/0xd0 | __alloc_pages+0xed/0x380 | new_slab+0x277/0x430 | ___slab_alloc.constprop.0+0xb6a/0xfc0 | __slab_alloc.constprop.0+0x42/0x80 | __kmalloc_node+0xcc/0x200 | xfs_attr_copy_value+0x6e/0x90 | xfs_attr_get+0xa0/0xc0 | xfs_get_acl+0xe4/0x210 | get_acl.part.0+0x55/0x110 | posix_acl_xattr_get+0x6a/0x120 | vfs_getxattr+0x172/0x1a0 | getxattr+0xb5/0x240 | __x64_sys_fgetxattr+0x66/0xb0 | do_syscall_64+0x59/0x80 | entry_SYSCALL_64_after_hwframe+0x44/0xae | | -> #0 (&xfs_nondir_ilock_class){++++}-{3:3}: | __lock_acquire+0x12cb/0x2320 | lock_acquire+0xc9/0x2e0 | down_write_nested+0x42/0x110 | xfs_icwalk_ag+0x365/0x810 | xfs_icwalk+0x38/0xa0 | xfs_reclaim_inodes_nr+0x90/0xc0 | super_cache_scan+0x18e/0x1f0 | shrink_slab.constprop.0+0x1cf/0x4d0 | shrink_node+0x1e2/0x470 | balance_pgdat+0x26d/0x5b0 | kswapd+0x224/0x4e0 | kthread+0x17a/0x1a0 | ret_from_fork+0x1f/0x30 | | other info that might help us debug this: | | Possible unsafe locking scenario: | CPU0 CPU1 | ---- ---- | lock(fs_reclaim); | lock(&xfs_nondir_ilock_class); | lock(fs_reclaim); | lock(&xfs_nondir_ilock_class); | | *** DEADLOCK *** | | 3 locks held by kswapd1/510: | #0: ffffffff82a76d60 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x4c4/0x5b0 | #1: ffffffff82a69d58 (shrinker_rwsem){++++}-{3:3}, at: shrink_slab.constprop.0+0x3b/0x4d0 | #2: ffff888553ccd0e8 (&type->s_umount_key#32){++++}-{3:3}, at: super_cache_scan+0x38/0x1f0 | | stack backtrace: | CPU: 12 PID: 510 Comm: kswapd1 Not tainted 5.16.0-rc1+ #12 | Hardware name: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.02.03.0003.041920141333 04/19/2014 | Call Trace: | | dump_stack_lvl+0x45/0x59 | check_noncircular+0xff/0x110 | __lock_acquire+0x12cb/0x2320 | lock_acquire+0xc9/0x2e0 | ? xfs_icwalk_ag+0x365/0x810 | ? lock_is_held_type+0xd6/0x130 | down_write_nested+0x42/0x110 | ? xfs_icwalk_ag+0x365/0x810 | xfs_icwalk_ag+0x365/0x810 | xfs_icwalk+0x38/0xa0 | xfs_reclaim_inodes_nr+0x90/0xc0 | super_cache_scan+0x18e/0x1f0 | shrink_slab.constprop.0+0x1cf/0x4d0 | shrink_node+0x1e2/0x470 | balance_pgdat+0x26d/0x5b0 | ? lock_is_held_type+0xd6/0x130 | kswapd+0x224/0x4e0 | ? wait_woken+0x90/0x90 | ? balance_pgdat+0x5b0/0x5b0 | kthread+0x17a/0x1a0 | ? set_kthread_struct+0x40/0x40 | ret_from_fork+0x1f/0x30 | It appears to be related to commit d634525db63e9 ("xfs: replace kmem_alloc_large() with kvmalloc()") as SLUB's new_slab() has | return allocate_slab(s, | flags & (GFP_RECLAIM_MASK | GFP_CONSTRAINT_MASK), node); which drops the __GFP_NOLOCKDEP as used in xfs_attr_copy_value(): | args->value = kvmalloc(valuelen, GFP_KERNEL | __GFP_NOLOCKDEP); However I can't tell if this should happen or not I'm just pointing out that it is. Sebastian