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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78C26D42BB3 for ; Tue, 12 Nov 2024 17:14:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D5956B009F; Tue, 12 Nov 2024 12:14:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 05C796B00F8; Tue, 12 Nov 2024 12:14:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3F986B00F9; Tue, 12 Nov 2024 12:14:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id BF3D26B009F for ; Tue, 12 Nov 2024 12:14:34 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3F8661204A0 for ; Tue, 12 Nov 2024 17:14:34 +0000 (UTC) X-FDA: 82778091060.15.1998D02 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf20.hostedemail.com (Postfix) with ESMTP id E6D6E1C002F for ; Tue, 12 Nov 2024 17:13:39 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=zWRGxxwv; dkim=pass header.d=linutronix.de header.s=2020e header.b=XbBCMGA2; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf20.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731431610; a=rsa-sha256; cv=none; b=zHAOdxS8x6AnJ9hREA/qe9eH3cCOuxkulORohZSF2Kn3zfxUXw8AfVyImwOQeec5eUjXMy sbWes7vD/ZGXUIO+OMwGA4J1pp5BQSFKQVpb0ATbj0UDxIcW99p+VK0Ba3ute4xOLSK8kq SnO1l/3Sz3LTp31Wcf0c5YEfc3RyUzw= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=zWRGxxwv; dkim=pass header.d=linutronix.de header.s=2020e header.b=XbBCMGA2; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf20.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731431610; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fLSGSsbdaiZ6JUBSPFVjQaHTBzfxSyRl8vuArkyUJAs=; b=DV7sQgg52y7FxM09EK7HOJY+cuRO0tWuldl+FHqxNfGm0lQasDwSbVAZX1hpFEjy3weDtb 7AiDIe0Butc9mDAEFRFkgmUhfN1VdjNXA+dsU47QLZHXwV5peFODjB1C7Un5jCkCcz53Oi mUG8LjFQ1PoD3cOebl3lo/P0sDMWzf4= Date: Tue, 12 Nov 2024 18:14:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1731431669; 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: in-reply-to:in-reply-to:references:references; bh=fLSGSsbdaiZ6JUBSPFVjQaHTBzfxSyRl8vuArkyUJAs=; b=zWRGxxwvUomZz2ou/p/A3prEpsitfkJlzoi55RFCGH6L6nF+VtL6L6auxDo7Oe/u74hBnQ 9/o/xErl3Dt8Zjuz6010t84GKYAL41pLMljW/E+0pCfNBk0yZ7BMdhDakRAcFi9XEcFNPa QGzGuGbkpIUQkzY/dlZewnYNVFNHsrgKWMlunaC8ghudyCLyxHkPRteduYUchfgkW4vawu yCTJrZr3KMbyb55pRgwba13gvVI9W2Y4I4MwGzBxE8CfvMi0EU/6opviX54Y/u8lLBidKh 0zJIFza1ApvBf4Fgy9Yqmej9iFtuAx1LtNO59NNUs8cAJl1i3Cp/F2mzcSpjlQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1731431669; 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: in-reply-to:in-reply-to:references:references; bh=fLSGSsbdaiZ6JUBSPFVjQaHTBzfxSyRl8vuArkyUJAs=; b=XbBCMGA2XMMqf1ILPCkgK8507FyvT6FWiYczNcIbxgasO5RneCbS/dxLprzBzaCeiF/R8j HoEG7mwJB8xSUlAg== From: Sebastian Andrzej Siewior To: Dave Chinner Cc: Alex Shi , linux-xfs@vger.kernel.org, Linux-MM , "linux-kernel@vger.kernel.org" Subject: Re: xfs deadlock on mm-unstable kernel? Message-ID: <20241112171428.UqPpObPV@linutronix.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: E6D6E1C002F X-Rspamd-Server: rspam11 X-Stat-Signature: bss7fjiwdxs6qib93dwscpnroum9swhw X-HE-Tag: 1731431619-710475 X-HE-Meta: U2FsdGVkX18qWBeiUQTx8Tpzy/Z/xlOiPuN+CBJWbA6xaQGj8cXebXscM7MZ6pw3gM5ROvmr+2dhGScj+nGTONDo4RYPkEqGNgRd+5f4UyHxmLR3GM3kZJLu1a+qt/AH6mpW4Qv9vLZnXBKMyfGCBz27gSD2XpUuGTdy9BAGrkJrHxVo2QFbBleU4S7Iok4fCT09VDVyF4KUeALFl73Kd1afDUqf6TOXUtRsfMx2tlhq5VYlNkdRO6MurF0Rbgw+7MkkQbeoTVocckBO3ywsn4KYecNAa421+WIwES3scpYpR7X1hZ81GSbElrgqRWu3Hz7rA04/G6k5wK+lG/bm+0ryBdCPhc9l5Qrcm/kEIutz4vYL5rUn5RI//sM6F0Qq0Ngq7xYGjT9NKVciNwo8dtgGO84/mfzgL5wTaN5e6jyPWGYgWXuAD8lfFvWB8gpeBgWfb6kMLyu2fQWE2prsWAqc1cP/WCQpFA4gtZ0qylyd5IJHz4wcTRZEGECyKRKTu8OWMrC4PD5+eFORXhPa2CQj1lp1TNqMdxJGT8lCg5FkqW0XzJk5W6Yx/oN0FFlO5hx7TIwx+AayXcdGYE+J0X6WPO1d61TcWPNyQ872BvmsDRoa8o9T+ufvAb50zJiUa55GbmAVGj45Z6G9+xeV3UoolsN35jh1gSLL+Byju2/9bApjJ+aVf187Gsq0cX9qfZlMz7COLxM05WliLljx+eHySygmPccQul98uH2X+Z8KaSTdDyx0FGkjDvBnYmR43/YfskkHN+X3LZ/dxKPqaqkoCHohQ3AUDhXIIOXtTfPTJPqDWa65CxidlWodCrhgxZSUH9a9QcmqHVpBxNfkvHlSaoUobRj86nzotjERU5dKIi9FqA6ffJ2U/ekJ6HuAUliriXUK2qOQGjG1OpLC2yiudwJ4E1WF6memn/6pFfRZh+Ugr8fIFPx04FDnnc/xP4lT82A0ffxiIaKwbsZ vOUO3ORS Cq0OcufcN8hj0i4F3pTNLttDWJcupXV/COse3deE+NiMw4KJrxmg/xxbJCVAJcSeiAxIpwvwvIun6bO7+k1z5ciM3jj+Wd1qFq0UYHqL8QCT+ZK1te55A3T1J5MhRiovFd9m1JCgAh0wFxrk1gSALnp5RMPl34gOan+mV23Hr74W6HxUKqPLErNyc7ZQk3zG3OA5xlWA0IeBAjRdWmUxvg/kKjfKpcisIOrrpnhlqsS0OcC4qUSysWK/xfw== 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: List-Subscribe: List-Unsubscribe: On 2024-07-08 20:14:44 [+1000], Dave Chinner wrote: > On Mon, Jul 08, 2024 at 04:36:08PM +0800, Alex Shi wrote: > > 372.297234][ T3001] ============================================ > > [ 372.297530][ T3001] WARNING: possible recursive locking detected > > [ 372.297827][ T3001] 6.10.0-rc6-00453-g2be3de2b70e6 #64 Not tainted > > [ 372.298137][ T3001] -------------------------------------------- > > [ 372.298436][ T3001] cc1/3001 is trying to acquire lock: > > [ 372.298701][ T3001] ffff88802cb910d8 (&xfs_dir_ilock_class){++++}-{3:3}, at: xfs_reclaim_inode+0x59e/0x710 > > [ 372.299242][ T3001] > > [ 372.299242][ T3001] but task is already holding lock: > > [ 372.299679][ T3001] ffff88800e145e58 (&xfs_dir_ilock_class){++++}-{3:3}, at: xfs_ilock_data_map_shared+0x4d/0x60 > > [ 372.300258][ T3001] > > [ 372.300258][ T3001] other info that might help us debug this: > > [ 372.300650][ T3001] Possible unsafe locking scenario: > > [ 372.300650][ T3001] > > [ 372.301031][ T3001] CPU0 > > [ 372.301231][ T3001] ---- > > [ 372.301386][ T3001] lock(&xfs_dir_ilock_class); > > [ 372.301623][ T3001] lock(&xfs_dir_ilock_class); > > [ 372.301860][ T3001] > > [ 372.301860][ T3001] *** DEADLOCK *** > > [ 372.301860][ T3001] > > [ 372.302325][ T3001] May be due to missing lock nesting notation > > [ 372.302325][ T3001] > > [ 372.302723][ T3001] 3 locks held by cc1/3001: > > [ 372.302944][ T3001] #0: ffff88800e146078 (&inode->i_sb->s_type->i_mutex_dir_key){++++}-{3:3}, at: walk_component+0x2a5/0x500 > > [ 372.303554][ T3001] #1: ffff88800e145e58 (&xfs_dir_ilock_class){++++}-{3:3}, at: xfs_ilock_data_map_shared+0x4d/0x60 > > [ 372.304183][ T3001] #2: ffff8880040190e0 (&type->s_umount_key#48){++++}-{3:3}, at: super_cache_scan+0x82/0x4e0 > > False positive. Inodes above allocation must be actively referenced, > and inodes accees by xfs_reclaim_inode() must have no references and > been evicted and destroyed by the VFS. So there is no way that an > unreferenced inode being locked for reclaim in xfs_reclaim_inode() > can deadlock against the refrenced inode locked by the inode lookup > code. > > Unfortunately, we don't have enough lockdep subclasses available to > annotate this correctly - we're already using all > MAX_LOCKDEP_SUBCLASSES to tell lockdep about all the ways we can > nest inode locks. That leaves us no space to add a "reclaim" > annotation for locking done from super_cache_scan() paths that would > avoid these false positives.... So the former inode (the one triggering the reclaim) is created and can not be the same as the one in reclaim list. Couldn't we assign it a different lock-class? My guess would be that you drop the lockdep_set_class() in xfs_setup_inode() and then do it in xfs_iget_cache_miss() before adding it to the tree. So you would have one class initially and then change it once it enters the tree. I guess once the inode is removed from the tree, it goes to kfree(). > -Dave. Sebastian