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 1CA49D637C4 for ; Wed, 13 Nov 2024 22:24:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A09D56B008C; Wed, 13 Nov 2024 17:24:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9BA0E6B0093; Wed, 13 Nov 2024 17:24:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 882496B0095; Wed, 13 Nov 2024 17:24:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 6DC1F6B008C for ; Wed, 13 Nov 2024 17:24:01 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E2D421405F4 for ; Wed, 13 Nov 2024 22:24:00 +0000 (UTC) X-FDA: 82782500220.28.47044D6 Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by imf12.hostedemail.com (Postfix) with ESMTP id 54AFA4000A for ; Wed, 13 Nov 2024 22:23:39 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=QEYrR2Im; spf=pass (imf12.hostedemail.com: domain of david@fromorbit.com designates 209.85.215.178 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731536464; 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=XhU1DTFWsUZULhpNS1f0hFA10SN7OegQFOrkLjd72jU=; b=fdjDLPgmkLxZtDluJUhH/L3eL0DRTN7mcblOXIFTFJ7eA2DWASFRaiolWrZoGVReoy7lpM BXspHLVZ/IbFzYFTpJ5yKN1fw758bn0rvU9A9hIwAy61dLRORVFEutEhR36xhRsCm0IhDp r8QHJE3Fj7TqC7q8PkBYDGOKEtp2FmI= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=QEYrR2Im; spf=pass (imf12.hostedemail.com: domain of david@fromorbit.com designates 209.85.215.178 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731536464; a=rsa-sha256; cv=none; b=f5ZOWscVvNMd5AqhDfryqZwOO+9miY63hGyR5aGmHQMw55gTayMevibRqwrGk2TTDzR5SL 13WV4zF/I77/dZMDeZhbb1O1sEb3CvfLJAkp7rNN/YahB566foFQSKeuEakSUObkN+9dXj 639oJL+asBGxuGzs2OY0J9ozSWqcBGE= Received: by mail-pg1-f178.google.com with SMTP id 41be03b00d2f7-7f12ba78072so5697861a12.2 for ; Wed, 13 Nov 2024 14:23:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1731536637; x=1732141437; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=XhU1DTFWsUZULhpNS1f0hFA10SN7OegQFOrkLjd72jU=; b=QEYrR2Imv9RWHnhdXlF7HTpEXjFtHb4imIOSwvvdbGiShKKZoJ+rP6L1OYcuHggkNP jywhr+aDC/Z2dWOQpOEsZVn4c9WPpvKp2wKKpm+JLMeRdCuRuUarzrnLMctcl0nFor4/ U66Z7mAv++zNOGqXE2FYkF5VQzcjk3jT3S7vD6chwU6Jmg4qtYM0sBrt7RvKWYHg6tjb 6mL9ke/5Wqp7olxJA3W2AO01Yj4FjuQ8C57LoOSq38ocrTIzgDVyNe+c9ND8N4l94WYK YOblCpQ8s1D12P7qZWzbTPTJiNT+h9lEU215l2YaSgeY+oGLkXU/PjZlJVnfa1pmPHIE W4aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731536637; x=1732141437; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XhU1DTFWsUZULhpNS1f0hFA10SN7OegQFOrkLjd72jU=; b=GhLoDSyCJJMrgZvknHsH9NclJG1rvTxpl765716e8kGAW+3C4vWxrR1fVF22SDvhSR QDYtidkJmtBBXdpbMFUe45XdJ6Ax+FRQr4VaQbcBRZElBPMzX0buGZ6VtRnuuFFn9vpR YCGp3SR6HlHhabpy98HSzLDjwIkSMo+N85eJy6p2SDMBmZmNBcIcMSXgfhYMsdzaSixa 1C3+mQ6oZEX530qsTHcTpieYSadO0NjlaWxYynCGui5XiM4K6NuaVgVzpYss89viK+kq U1g4yAHjW+GKmPLx01DnAzRAPFWG8mzHjrAm2vniTVUxSPv13NUTQ0WNiGE5OxaLZoV9 j4Aw== X-Forwarded-Encrypted: i=1; AJvYcCVAdmYxQygYXxMNm6lrJ83FstDhng+w0ZfkT1qcI9TyTpAohm0B0d3xB0t47VS95Df4R+YMi/aUPw==@kvack.org X-Gm-Message-State: AOJu0YwDm78ftFtdRj8pSOvOzyM6YQrG0tuWZTTTP5SnJZr+kpniSmvo +Kdg8yjaKT1dltJUr3B6Ytiy/jXZRCfiW3Yw0CBEREqohowL2h5g6Urz1oNYMJs= X-Google-Smtp-Source: AGHT+IFp+u01htZ7+R4q0w8zY+0n6pwR7q3KOwbId/6FUz/GheGxoVBPUTfGzcZ0P6rKeXYjD5vOXg== X-Received: by 2002:a05:6a20:748b:b0:1d9:c78f:4207 with SMTP id adf61e73a8af0-1dc2292c2a4mr30095003637.11.1731536630122; Wed, 13 Nov 2024 14:23:50 -0800 (PST) Received: from dread.disaster.area (pa49-186-86-168.pa.vic.optusnet.com.au. [49.186.86.168]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-7f7127f3b01sm2017218a12.84.2024.11.13.14.23.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Nov 2024 14:23:49 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1tBLm6-00EGof-0x; Thu, 14 Nov 2024 09:23:46 +1100 Date: Thu, 14 Nov 2024 09:23:46 +1100 From: Dave Chinner To: Sebastian Andrzej Siewior 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: References: <20241112171428.UqPpObPV@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241112171428.UqPpObPV@linutronix.de> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 54AFA4000A X-Stat-Signature: s1t47p7hwzurufn3n53rzqk6qdag1h6b X-Rspam-User: X-HE-Tag: 1731536619-311315 X-HE-Meta: U2FsdGVkX19yUKXsxaDyIzQvrNAuw8Z1MKpwqwto1Bp/WNCwmicGHht7BjfFd0aZh0jKYh8REG1FWCkqiI01FQ3S9BMqFILvq8wExMqlkb5S44zF4LXDpO8sxiMCdnIrxtrBjHY6zlHKzXeSmGARGRAOYKPAtzXjLBZ+nuQ2QvrxgeRKtGkQBceIXQwyHbfOKECxTg5JteqQbQl3nBvO1mQCjw78WYPewbhyUPoiqKCd22BsNMVfKM2512GYUXlHOdHHg0n6WQErxSRueCryB+rKHg71Pu/WEIKeeLAgPpZKJ/yPhk+LWGXNSo/A9wjv/TKOgqvS1cTgEPiJ2FK9kCv+wKEWzZZtoGvKJg5qGmmuPGCAGpEnVn0mXNUGQD94VWNe3kiHASklNvyw1ryjL1RB7YWGd2a87RwEZMogcJWYzX8HJxSNbha8PDTCiBNk/ItqEH2R+HIBzdVcQlS9GMtpucTu4Kvxos6p/44DqIf07BI4hemrI7bVc63EUoM+1coWvSE4RHGMXFCoV4e6zhF5XVY+ktN+7vv2b0G0rjH14ZN0WHAjxO98of3eb2BD7x3y8w2C8KZa0hkUIasW4lwKLCFyIFFzQhxPygSL0lc6m5bGXlUAdlTagCMcb4k94vR2/EKZCJaUYRFZ4LkTSpdxHuhF35s/SrBsu7DOxyzYmhWJxuLcnnq2zsObZ/RzPLVAlrF3zanUvgHTurEM9gBcunMkwoupv4gj0XyXcyojI2PWH5fLbvZKmhJhdFQUsOr7O/OWDyZKBDVAuVFfSz+Jfmy3Y2j81Ae98QhNO1ttsEYGwY+i2DSaevRBg4sk4e+QjXpTfYynXdlOIu6oHwK1I7PkutqKiyr3K+3iLNHxMqsywwO/BOOObIX4Td1OhfvV9+PVA6SiS0m9hfQeCLYVz4QBFP2ZMdrFDKe7kjqJ99hhrTvqQUsA8td36v3ZCV/Mj9MkqTjWrtBGbhm 29z2Ohzj b2sSPLDv+uImLOG8xJ7G562unwD9+O8u+Qtynyf+VcKkx+lrk5oVQmEK+IBRFBsHlPxmpI+Ar/gZEqpJ+QuNazxONYCIib23A0jVxz5jTKDAHUMDHQtk5wPqfvWi/CMWTQU02nY2oN/n43IfSyuS/JZMi5nBIbanHjgKIprR+X+2LrHGK00HurP7u3M2E0+pvJTo1dNznCrgonrcXEvxpvcmLiHoztF3jW6/pKpNdbvECNXcc6ji5l5KSFk8fG5YbyjQfeemJvvvp/Jv+p5+2oDHVOndNkQ8bDiLL4Y9PHV+8OwVaKgNgRr4Auj9ZOBidFQWZg1fTkrtFQThaeTZa9p/5btca5cRMnMtcxo6hv1vpbkuag+W2Qj5UPZ+qP9A81USTf8zNcxwnqZDPgFi3tJ9kfenk5ePbhTpcxE/q6agXThvmml9cD+01LIx3MYuUWpthgYqxVDp1xyLpN1Bhk6drQMMjs0TAhp0Zsk7y/+ZTKGJrngE12mZGdw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001830, 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 Tue, Nov 12, 2024 at 06:14:28PM +0100, Sebastian Andrzej Siewior wrote: > 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? We've done that in the past. The problem with that is we lose lock ordering verification across reclaim. i.e. inode lock ordering must be the same both above and below reclaim, and changing the lock class loses the ability to verify this. This is important to us as some code (e.g. extent removal) can be called from both above and below reclaim, and they require the same transaction and inode lock contexts to be held regardless of where they are called from... -Dave. -- Dave Chinner david@fromorbit.com