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 1B308C30658 for ; Tue, 2 Jul 2024 05:55:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8D4BF6B0082; Tue, 2 Jul 2024 01:55:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 85D7C6B0083; Tue, 2 Jul 2024 01:55:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6AF916B0085; Tue, 2 Jul 2024 01:55:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4223C6B0082 for ; Tue, 2 Jul 2024 01:55:17 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B3393A3849 for ; Tue, 2 Jul 2024 05:55:16 +0000 (UTC) X-FDA: 82293749832.06.3EACF68 Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) by imf22.hostedemail.com (Postfix) with ESMTP id B78F2C0006 for ; Tue, 2 Jul 2024 05:55:14 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=BwrgK0Oa; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf22.hostedemail.com: domain of david@fromorbit.com designates 209.85.167.171 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719899698; a=rsa-sha256; cv=none; b=lxJgZprCcYW/ft9VPz1ZAzBnINEAzZr+Z4MAX42c0iAw/uOKu1ko2ls49Rmis1JdOc6UTH Yj5GAUFnK+UsYQJJCBoLOZ+dTVEll2zzyEDVYaHyYC8QtFcX0crnRkWlVXxhRxThyQkOLe vvjzkgpIXNipVLdQ0mNbEDdOjQe207E= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=BwrgK0Oa; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf22.hostedemail.com: domain of david@fromorbit.com designates 209.85.167.171 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719899698; 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=rmkheATIgV0EPHSlh+7AbFF8dPmUkG6VN5nv2fkaE3U=; b=nV76LeYx7LGi8EB1142v953/8yQX+/2eCjj5b5XzWsdwr14Nwskdr7+fhwNyGfNhwJ0Z7e 6QOFdvpIEBVqSG87G7Pphda0f+6h1XaXmLZzgVES3TBTvx2fwx8V3kSbbzFaWQnGZWhMJD 5ipQcuALXxiwT/xJZ50mXNyUXfmIp48= Received: by mail-oi1-f171.google.com with SMTP id 5614622812f47-3d55c0fadd2so2396468b6e.3 for ; Mon, 01 Jul 2024 22:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1719899713; x=1720504513; 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=rmkheATIgV0EPHSlh+7AbFF8dPmUkG6VN5nv2fkaE3U=; b=BwrgK0Oa5p6LbBqj71i/RcMYUipa1WjZXXuAsYhADK19lWujI5Vra8nK2ose8wkPcp cJJ8oNMt+vM8D5O0tydGp9IzcwAC4iweINLbVjGwTJ3bfkl6IYWuyW8/9bL1641FsWXe xL8mWaOq9qkxYhFd8755Q5RscHV28iXVRUMAZVrCP9sdXmQf8V2P5sL8Qtng1ei7pJFH SNHGacHVKuvapXILs45ylR54lqjg1us8nt7DX1IWTyI1tutD9G7GLrqDVWWEe9fe596q /HGEY1LXyycNnKRDwag9YvhgF+/QtPF8bM9tFNRL7UUQvQ91MlAozN+nSnFG9V6wpgTc hhuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719899713; x=1720504513; 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=rmkheATIgV0EPHSlh+7AbFF8dPmUkG6VN5nv2fkaE3U=; b=hFlnbLvRTV+NXvW+sTYVo7DpnvOj1nlANi3VcYMBYIoRFaOfRdb+uoMPLddo6farOF x07VB/pRns39Io91VKM6aah0CFNWiowVgTNFGhjHf0eA0yoURQuBuOi8oxtIgp+3sTjb UleESfljAJQ5UYcw6RDj4L1a0UoS8zEzq4oH/YMLH5kJW0Lh3ZSR03gPCxQANGRi9ZiL crXRt/LtYrZ/dBOUcfDN9ao5Rpuc0fSmm7kZxCqc4qe3p2ejAv+3WIREE9gXH6A7JyPB IpJdoUAevbAhX64OaMqvf++5YEwenTuO1jm55zLLUjs5azeu5nZP36QcMugOG3WMOUEl 3JyA== X-Forwarded-Encrypted: i=1; AJvYcCUHQf0ldA97eqgnEUe6OqvoXZwgXcTTsSHh65Jl3G+NPkW5/zcJdAUdn33FBVpNdgJPFKqNW+UqCVr8DxqcpLlFezo= X-Gm-Message-State: AOJu0YwVST3kAeZhTZmF55mxjGj4Xh1XWA3yJ0lVBfOgvwpO5r5215ml y5STrwxxKgbNgXYuTBka5ntANp94KCMaIfHvZ6lyKxtyaaImC9Sk51mo6e0EGkk= X-Google-Smtp-Source: AGHT+IHO+SY1lPsx22bhXTxjoF9rc12IRcJ6e6RBMW6DYu0rPxhqZVKyeW0SpRsj7vAzXwaovFUXig== X-Received: by 2002:a05:6808:1909:b0:3d5:6312:a017 with SMTP id 5614622812f47-3d6b32e5a46mr10244393b6e.29.1719899713463; Mon, 01 Jul 2024 22:55:13 -0700 (PDT) Received: from dread.disaster.area (pa49-179-32-121.pa.nsw.optusnet.com.au. [49.179.32.121]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-708044b1112sm7566445b3a.182.2024.07.01.22.55.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jul 2024 22:55:13 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1sOWTu-001Adu-29; Tue, 02 Jul 2024 15:55:10 +1000 Date: Tue, 2 Jul 2024 15:55:10 +1000 From: Dave Chinner To: Long Li Cc: willy@infradead.org, linux-mm@kvack.org, linux-xfs@vger.kernel.org Subject: Re: [PATCH 07/12] xfs: use __GFP_NOLOCKDEP instead of GFP_NOFS Message-ID: References: <20240115230113.4080105-1-david@fromorbit.com> <20240115230113.4080105-8-david@fromorbit.com> <20240622094411.GA830005@ceph-admin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240622094411.GA830005@ceph-admin> X-Rspamd-Queue-Id: B78F2C0006 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: renidme4qep9o395chm4ya1oyyy4bbow X-HE-Tag: 1719899714-2330 X-HE-Meta: U2FsdGVkX1/JeCwKY+tSeQk7ICoizwzdlSAgA2+aUeyW4VOC0Wq/6v3G/1WFiVIhsk2iZE/SAv/YfNGkWx+j+X1ISJzOgLWGt/gBlWwdbaHyqVyWK14liG4hK2R8/1i3q+1BBSToYQf/9/0oqiDrCikx7UoMNpgOEx+X5ZT6b/57OfyhfmEyPMjodZMat5D/7I4mSh7C0WkevxVncbMspAGmZ30ZcRmBO4AJlmBo0gKfkTaVtu2LBrYYR4Fbn6GfKJpRwfJvnbMIpFfbAkdjnnX7sT2Hff0UUra7w1PFSH7ggvLrBORHrBNaVPFIKgig6clU8XeFwsKn346dYg45TydBkrx79kIHgJKshikl30RifUuVPxFdrThPuzGH/IX9Al4/YN947LAonXVBOEHx1ZvZnBSLwzZeLXA4G2eYbEivWvv77HZIX2yMlwQwcTAE/kegH6SNlxLG6UNVTzqNI6RAK0nq7EQCeMfa+zjFgqg4YJnksD6VNXYtp4P2hekZf7ob63KuiLaF2qPkyUMmOT6n7I2NMjVn7WRYNl4o6yanclwRhUM47F2eLJmaLp8du/km8/JzJbiHjX/73FDRa75K8Ia1y89ytzFBaPqDdmF57Bs4O3Qv7hYwLphwl/CFQ/8moZBuJK+Kdzd9+yr1SOu1E0aF3bGMB/JtC6D/QzqvYCxvekyY0ELv91j+YF59Q/Jq1pxqcIt9tARspAbU9Vho0/s1nwCYdBgF12UOW4Wj77be4y8KUZ9CssF+BRxx5O9vECUTn3IKzRYMkUUXKdw8GwzkSh2+7i+MD9JMyZ5ySp4MA1+1Crz0bSF3WFUKPe7grmEIWDF0kt1Bbf4rNmXcYR5V2Qs9fwsaVe5N5hF2lWUB0UCopDmaLyW66MddqKArhTKQuHnU1TFHw4Ggw0A0K9cxhyur/cM9imA0+JEdRbpXUOnokFgx4DNCWquEUFENkExaJ5Dg7BzCe6g qrsJFIHI r77uoxTaFXJl/TCgo1Pf+dQf+J5MKRORXHaFlKQ4lbS3f3R5l579C0xHXDdM8HzGApDmEVO23rN7IoMyojCx5ACDZDHw7iRHSN+UB+UI9AvO650s0g+AF5xX4D0MrTWlvimBdt3brmH0PB49Q1ljxQE3F+SWXLeldYxv8BKLOfQdvp1FngmYo7rpo55B/PX7+RU4UaYwu/+kYX4cUbdyW5bM/eJQwhPHaBsQeAfp1IKl0RJ78hs36qRIaD+zQ0gjQRaCj1cqxUT/uxDp3huJGBBnvEAuCAA+2qkqo/TFIldOJb2gNxdYF/4QBAlz/6FZ7Dv4e+raGA1Ii4p5ksyHdoiDAfr31h5x0+eNOnTUHzAC6rvopL5LGg3ZZ81yrXG7KrgJbZtzcGRVqnleSfg/DlpbLs1KfqI8oNNGaACtxTY1qeMm66hzPlZMxR3zsIbzrNZ8nW6d+SC3CtZc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000693, 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 Sat, Jun 22, 2024 at 05:44:11PM +0800, Long Li wrote: > On Tue, Jan 16, 2024 at 09:59:45AM +1100, Dave Chinner wrote: > > From: Dave Chinner > > > > In the past we've had problems with lockdep false positives stemming > > from inode locking occurring in memory reclaim contexts (e.g. from > > superblock shrinkers). Lockdep doesn't know that inodes access from > > above memory reclaim cannot be accessed from below memory reclaim > > (and vice versa) but there has never been a good solution to solving > > this problem with lockdep annotations. > > > > This situation isn't unique to inode locks - buffers are also locked > > above and below memory reclaim, and we have to maintain lock > > ordering for them - and against inodes - appropriately. IOWs, the > > same code paths and locks are taken both above and below memory > > reclaim and so we always need to make sure the lock orders are > > consistent. We are spared the lockdep problems this might cause > > by the fact that semaphores and bit locks aren't covered by lockdep. > > > > In general, this sort of lockdep false positive detection is cause > > by code that runs GFP_KERNEL memory allocation with an actively > > referenced inode locked. When it is run from a transaction, memory > > allocation is automatically GFP_NOFS, so we don't have reclaim > > recursion issues. So in the places where we do memory allocation > > with inodes locked outside of a transaction, we have explicitly set > > them to use GFP_NOFS allocations to prevent lockdep false positives > > from being reported if the allocation dips into direct memory > > reclaim. > > > > More recently, __GFP_NOLOCKDEP was added to the memory allocation > > flags to tell lockdep not to track that particular allocation for > > the purposes of reclaim recursion detection. This is a much better > > way of preventing false positives - it allows us to use GFP_KERNEL > > context outside of transactions, and allows direct memory reclaim to > > proceed normally without throwing out false positive deadlock > > warnings. > > Hi Dave, > > I recently encountered the following AA deadlock lockdep warning > in Linux-6.9.0. This version of the kernel has currently merged > your patch set. I believe this is a lockdep false positive warning. Yes, it is. > The xfs_dir_lookup_args() function is in a non-transactional context > and allocates memory with the __GFP_NOLOCKDEP flag in xfs_buf_alloc_pages(). > Even though __GFP_NOLOCKDEP can tell lockdep not to track that particular > allocation for the purposes of reclaim recursion detection, it cannot > completely replace __GFP_NOFS. We are not trying to replace GFP_NOFS with __GFP_NOLOCKDEP. What we are trying to do is annotate the allocation sites where lockdep false positives will occur. That way if we get a lockdep report from a location that uses __GFP_NOLOCKDEP, we know that it is either a false positive or there is some nested allocation that did not honor __GFP_NOLOCKDEP. We've already fixed a bunch of nested allocations (e.g. kasan, kmemleak, etc) to propagate the __GFP_NOLOCKDEP flag so they don't generate false positives, either. So the amount of noise has already been reduced. > Getting trapped in direct memory reclaim > maybe trigger the AA deadlock warning as shown below. No, it can't. xfs_dir_lookup() can only lock referenced inodes. xfs_reclaim_inodes_nr() can only lock unreferenced inodes. It is not possible for the same inode to be both referenced and unreferenced at the same time, therefore memory reclaim cannot self deadlock through this path. I expected to see some situations like this when getting rid of GFP_NOFS (because now memory reclaim runs in places it never used to). Once I have an idea of the sorts of false positives that are still being tripped over, I can formulate a plan to eradicate them, too. -Dave. -- Dave Chinner david@fromorbit.com