From: Dave Chinner <david@fromorbit.com>
To: Qian Cai <cai@lca.pw>
Cc: "Daniel Vetter" <daniel.vetter@ffwll.ch>,
"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
"DRI Development" <dri-devel@lists.freedesktop.org>,
LKML <linux-kernel@vger.kernel.org>,
amd-gfx@lists.freedesktop.org,
"Thomas Hellström" <thomas_os@shipmail.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Jason Gunthorpe" <jgg@mellanox.com>,
linux-mm@kvack.org, linux-rdma@vger.kernel.org,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Christian König" <christian.koenig@amd.com>,
"Daniel Vetter" <daniel.vetter@intel.com>,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH] mm: Track mmu notifiers in fs_reclaim_acquire/release
Date: Wed, 24 Jun 2020 08:31:35 +1000 [thread overview]
Message-ID: <20200623223134.GC2005@dread.disaster.area> (raw)
In-Reply-To: <20200621174205.GB1398@lca.pw>
On Sun, Jun 21, 2020 at 01:42:05PM -0400, Qian Cai wrote:
> On Wed, Jun 10, 2020 at 09:41:01PM +0200, Daniel Vetter wrote:
> > fs_reclaim_acquire/release nicely catch recursion issues when
> > allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
> > to use to keep the excessive caches in check). For mmu notifier
> > recursions we do have lockdep annotations since 23b68395c7c7
> > ("mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end").
> >
> > But these only fire if a path actually results in some pte
> > invalidation - for most small allocations that's very rarely the case.
> > The other trouble is that pte invalidation can happen any time when
> > __GFP_RECLAIM is set. Which means only really GFP_ATOMIC is a safe
> > choice, GFP_NOIO isn't good enough to avoid potential mmu notifier
> > recursion.
> >
> > I was pondering whether we should just do the general annotation, but
> > there's always the risk for false positives. Plus I'm assuming that
> > the core fs and io code is a lot better reviewed and tested than
> > random mmu notifier code in drivers. Hence why I decide to only
> > annotate for that specific case.
> >
> > Furthermore even if we'd create a lockdep map for direct reclaim, we'd
> > still need to explicit pull in the mmu notifier map - there's a lot
> > more places that do pte invalidation than just direct reclaim, these
> > two contexts arent the same.
> >
> > Note that the mmu notifiers needing their own independent lockdep map
> > is also the reason we can't hold them from fs_reclaim_acquire to
> > fs_reclaim_release - it would nest with the acquistion in the pte
> > invalidation code, causing a lockdep splat. And we can't remove the
> > annotations from pte invalidation and all the other places since
> > they're called from many other places than page reclaim. Hence we can
> > only do the equivalent of might_lock, but on the raw lockdep map.
> >
> > With this we can also remove the lockdep priming added in 66204f1d2d1b
> > ("mm/mmu_notifiers: prime lockdep") since the new annotations are
> > strictly more powerful.
> >
> > v2: Review from Thomas Hellstrom:
> > - unbotch the fs_reclaim context check, I accidentally inverted it,
> > but it didn't blow up because I inverted it immediately
> > - fix compiling for !CONFIG_MMU_NOTIFIER
> >
> > Cc: Thomas Hellström (Intel) <thomas_os@shipmail.org>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Jason Gunthorpe <jgg@mellanox.com>
> > Cc: linux-mm@kvack.org
> > Cc: linux-rdma@vger.kernel.org
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Cc: Christian König <christian.koenig@amd.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>
> Replying the right patch here...
>
> Reverting this commit [1] fixed the lockdep warning below while applying
> some memory pressure.
>
> [1] linux-next cbf7c9d86d75 ("mm: track mmu notifiers in fs_reclaim_acquire/release")
>
> [ 190.455003][ T369] WARNING: possible circular locking dependency detected
> [ 190.487291][ T369] 5.8.0-rc1-next-20200621 #1 Not tainted
> [ 190.512363][ T369] ------------------------------------------------------
> [ 190.543354][ T369] kswapd3/369 is trying to acquire lock:
> [ 190.568523][ T369] ffff889fcf694528 (&xfs_nondir_ilock_class){++++}-{3:3}, at: xfs_reclaim_inode+0xdf/0x860
> spin_lock at include/linux/spinlock.h:353
> (inlined by) xfs_iflags_test_and_set at fs/xfs/xfs_inode.h:166
> (inlined by) xfs_iflock_nowait at fs/xfs/xfs_inode.h:249
> (inlined by) xfs_reclaim_inode at fs/xfs/xfs_icache.c:1127
> [ 190.614359][ T369]
> [ 190.614359][ T369] but task is already holding lock:
> [ 190.647763][ T369] ffffffffb50ced00 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x30
> __fs_reclaim_acquire at mm/page_alloc.c:4200
> [ 190.687845][ T369]
> [ 190.687845][ T369] which lock already depends on the new lock.
> [ 190.687845][ T369]
> [ 190.734890][ T369]
> [ 190.734890][ T369] the existing dependency chain (in reverse order) is:
> [ 190.775991][ T369]
> [ 190.775991][ T369] -> #1 (fs_reclaim){+.+.}-{0:0}:
> [ 190.808150][ T369] fs_reclaim_acquire+0x77/0x80
> [ 190.832152][ T369] slab_pre_alloc_hook.constprop.52+0x20/0x120
> slab_pre_alloc_hook at mm/slab.h:507
> [ 190.862173][ T369] kmem_cache_alloc+0x43/0x2a0
> [ 190.885602][ T369] kmem_zone_alloc+0x113/0x3ef
> kmem_zone_alloc at fs/xfs/kmem.c:129
> [ 190.908702][ T369] xfs_inode_item_init+0x1d/0xa0
> xfs_inode_item_init at fs/xfs/xfs_inode_item.c:639
> [ 190.934461][ T369] xfs_trans_ijoin+0x96/0x100
> xfs_trans_ijoin at fs/xfs/libxfs/xfs_trans_inode.c:34
> [ 190.961530][ T369] xfs_setattr_nonsize+0x1a6/0xcd0
OK, this patch has royally screwed something up if this path thinks
it can enter memory reclaim. This path is inside a transaction, so
it is running under PF_MEMALLOC_NOFS context, so should *never*
enter memory reclaim.
I'd suggest that whatever mods were made to fs_reclaim_acquire by
this patch broke it's basic functionality....
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 13cc653122b7..7536faaaa0fd 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -57,6 +57,7 @@
> > #include <trace/events/oom.h>
> > #include <linux/prefetch.h>
> > #include <linux/mm_inline.h>
> > +#include <linux/mmu_notifier.h>
> > #include <linux/migrate.h>
> > #include <linux/hugetlb.h>
> > #include <linux/sched/rt.h>
> > @@ -4124,7 +4125,7 @@ should_compact_retry(struct alloc_context *ac, unsigned int order, int alloc_fla
> > static struct lockdep_map __fs_reclaim_map =
> > STATIC_LOCKDEP_MAP_INIT("fs_reclaim", &__fs_reclaim_map);
> >
> > -static bool __need_fs_reclaim(gfp_t gfp_mask)
> > +static bool __need_reclaim(gfp_t gfp_mask)
> > {
> > gfp_mask = current_gfp_context(gfp_mask);
This is applies the per-task memory allocation context flags to the
mask that is checked here.
> > @@ -4136,10 +4137,6 @@ static bool __need_fs_reclaim(gfp_t gfp_mask)
> > if (current->flags & PF_MEMALLOC)
> > return false;
> >
> > - /* We're only interested __GFP_FS allocations for now */
> > - if (!(gfp_mask & __GFP_FS))
> > - return false;
> > -
> > if (gfp_mask & __GFP_NOLOCKDEP)
> > return false;
> >
> > @@ -4158,15 +4155,25 @@ void __fs_reclaim_release(void)
> >
> > void fs_reclaim_acquire(gfp_t gfp_mask)
> > {
> > - if (__need_fs_reclaim(gfp_mask))
> > - __fs_reclaim_acquire();
> > + if (__need_reclaim(gfp_mask)) {
> > + if (gfp_mask & __GFP_FS)
> > + __fs_reclaim_acquire();
.... and they have not been applied in this path. There's your
breakage.
For future reference, please post anything that changes NOFS
allocation contexts or behaviours to linux-fsdevel, as filesystem
developers need to know about proposed changes to infrastructure
that is critical to the correct functioning of filesystems...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2020-06-23 23:02 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-04 8:12 [PATCH 00/18] dma-fence lockdep annotations, round 2 Daniel Vetter
2020-06-04 8:12 ` [PATCH 01/18] mm: Track mmu notifiers in fs_reclaim_acquire/release Daniel Vetter
2020-06-10 12:01 ` Thomas Hellström (Intel)
2020-06-10 12:25 ` [Intel-gfx] " Daniel Vetter
2020-06-10 19:41 ` [PATCH] " Daniel Vetter
2020-06-11 14:29 ` Jason Gunthorpe
2020-06-21 17:42 ` Qian Cai
2020-06-21 18:07 ` Daniel Vetter
2020-06-21 20:01 ` Daniel Vetter
2020-06-21 22:09 ` Qian Cai
2020-06-23 16:17 ` Qian Cai
2020-06-23 22:13 ` Daniel Vetter
2020-06-23 22:29 ` Qian Cai
2020-06-23 22:31 ` Dave Chinner [this message]
2020-06-23 22:36 ` Daniel Vetter
2020-06-21 17:00 ` [PATCH 01/18] " Qian Cai
2020-06-21 17:28 ` Daniel Vetter
2020-06-21 17:46 ` Qian Cai
2020-06-04 8:12 ` [PATCH 02/18] dma-buf: minor doc touch-ups Daniel Vetter
2020-06-10 13:07 ` Thomas Hellström (Intel)
2020-06-04 8:12 ` [PATCH 03/18] dma-fence: basic lockdep annotations Daniel Vetter
2020-06-04 8:57 ` Thomas Hellström (Intel)
2020-06-04 9:21 ` Daniel Vetter
[not found] ` <159126281827.25109.3992161193069793005@build.alporthouse.com>
2020-06-04 9:36 ` [Intel-gfx] " Daniel Vetter
2020-06-05 13:29 ` [PATCH] " Daniel Vetter
2020-06-05 14:30 ` Thomas Hellström (Intel)
2020-06-11 9:57 ` Maarten Lankhorst
2020-06-10 14:21 ` [Intel-gfx] [PATCH 03/18] " Tvrtko Ursulin
2020-06-10 15:17 ` Daniel Vetter
2020-06-11 10:36 ` Tvrtko Ursulin
2020-06-11 11:29 ` Daniel Vetter
2020-06-11 14:29 ` Tvrtko Ursulin
2020-06-11 15:03 ` Daniel Vetter
[not found] ` <159186243606.1506.4437341616828968890@build.alporthouse.com>
2020-06-11 8:44 ` Dave Airlie
2020-06-11 9:01 ` [Intel-gfx] " Daniel Stone
[not found] ` <159255511144.7737.12635440776531222029@build.alporthouse.com>
2020-06-19 8:51 ` Daniel Vetter
[not found] ` <159255801588.7737.4425728073225310839@build.alporthouse.com>
2020-06-19 9:43 ` Daniel Vetter
[not found] ` <159257233754.7737.17318605310513355800@build.alporthouse.com>
2020-06-22 9:16 ` Daniel Vetter
2020-07-09 7:29 ` Daniel Stone
2020-07-09 8:01 ` Daniel Vetter
2020-06-04 8:12 ` [PATCH 04/18] dma-fence: prime " Daniel Vetter
2020-06-11 7:30 ` [Linaro-mm-sig] " Thomas Hellström (Intel)
2020-06-11 8:34 ` Daniel Vetter
2020-06-11 14:15 ` Jason Gunthorpe
2020-06-11 23:35 ` Felix Kuehling
2020-06-12 5:11 ` Daniel Vetter
2020-06-19 18:13 ` Jerome Glisse
2020-06-23 7:39 ` Daniel Vetter
2020-06-23 18:44 ` Felix Kuehling
2020-06-23 19:02 ` Daniel Vetter
2020-06-16 12:07 ` Daniel Vetter
2020-06-16 14:53 ` Jason Gunthorpe
2020-06-17 7:57 ` Daniel Vetter
2020-06-17 15:29 ` Jason Gunthorpe
2020-06-18 14:42 ` Daniel Vetter
2020-06-17 6:48 ` Daniel Vetter
2020-06-17 15:28 ` Jason Gunthorpe
2020-06-18 15:00 ` Daniel Vetter
2020-06-18 17:23 ` Jason Gunthorpe
2020-06-19 7:22 ` Daniel Vetter
2020-06-19 11:39 ` Jason Gunthorpe
2020-06-19 15:06 ` Daniel Vetter
2020-06-19 15:15 ` Jason Gunthorpe
2020-06-19 16:19 ` Daniel Vetter
2020-06-19 17:23 ` Jason Gunthorpe
2020-06-19 18:09 ` Jerome Glisse
2020-06-19 18:18 ` Jason Gunthorpe
2020-06-19 19:48 ` Felix Kuehling
2020-06-19 19:55 ` Jason Gunthorpe
2020-06-19 20:03 ` Felix Kuehling
2020-06-19 20:31 ` Jerome Glisse
2020-06-22 11:46 ` Jason Gunthorpe
2020-06-22 20:15 ` Jerome Glisse
2020-06-23 0:02 ` Jason Gunthorpe
2020-06-19 20:10 ` Jerome Glisse
2020-06-19 20:43 ` Daniel Vetter
2020-06-19 20:59 ` Jerome Glisse
2020-06-23 0:05 ` Jason Gunthorpe
2020-06-19 19:11 ` Alex Deucher
2020-06-19 19:30 ` Felix Kuehling
2020-06-19 19:40 ` Jerome Glisse
2020-06-19 19:51 ` Jason Gunthorpe
2020-06-04 8:12 ` [PATCH 05/18] drm/vkms: Annotate vblank timer Daniel Vetter
2020-06-04 8:12 ` [PATCH 06/18] drm/vblank: Annotate with dma-fence signalling section Daniel Vetter
2020-06-04 8:12 ` [PATCH 07/18] drm/atomic-helper: Add dma-fence annotations Daniel Vetter
2020-06-04 8:12 ` [PATCH 08/18] drm/amdgpu: add dma-fence annotations to atomic commit path Daniel Vetter
2020-06-23 10:51 ` Daniel Vetter
2020-06-04 8:12 ` [PATCH 09/18] drm/scheduler: use dma-fence annotations in main thread Daniel Vetter
2020-06-04 8:12 ` [PATCH 10/18] drm/amdgpu: use dma-fence annotations in cs_submit() Daniel Vetter
2020-06-04 8:12 ` [PATCH 11/18] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code Daniel Vetter
2020-06-04 8:12 ` [PATCH 12/18] drm/amdgpu: DC also loves to allocate stuff where it shouldn't Daniel Vetter
2020-06-04 8:12 ` [PATCH 13/18] drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail Daniel Vetter
2020-06-05 8:30 ` Pierre-Eric Pelloux-Prayer
2020-06-05 12:41 ` Daniel Vetter
2020-06-04 8:12 ` [PATCH 14/18] drm/scheduler: use dma-fence annotations in tdr work Daniel Vetter
2020-06-04 8:12 ` [PATCH 15/18] drm/amdgpu: use dma-fence annotations for gpu reset code Daniel Vetter
2020-06-04 8:12 ` [PATCH 16/18] Revert "drm/amdgpu: add fbdev suspend/resume on gpu reset" Daniel Vetter
2020-06-04 8:12 ` [PATCH 17/18] drm/amdgpu: gpu recovery does full modesets Daniel Vetter
2020-06-04 8:12 ` [PATCH 18/18] drm/i915: Annotate dma_fence_work Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200623223134.GC2005@dread.disaster.area \
--to=david@fromorbit.com \
--cc=akpm@linux-foundation.org \
--cc=amd-gfx@lists.freedesktop.org \
--cc=cai@lca.pw \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jgg@mellanox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=thomas_os@shipmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).