| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <15bcdddd-b560-e98b-eaec-62277b5ab4af@shipmail.org>
Date: Wed, 10 Jun 2020 14:01:44 +0200
From: Thomas Hellström (Intel)
<thomas_os@...pmail.org>
To: Daniel Vetter <daniel.vetter@...ll.ch>,
DRI Development <dri-devel@...ts.freedesktop.org>
Cc: linux-rdma@...r.kernel.org,
Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
LKML <linux-kernel@...r.kernel.org>,
amd-gfx@...ts.freedesktop.org, linux-mm@...ck.org,
Jason Gunthorpe <jgg@...lanox.com>,
Daniel Vetter <daniel.vetter@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Christian König <christian.koenig@....com>
Subject: Re: [PATCH 01/18] mm: Track mmu notifiers in
fs_reclaim_acquire/release
Hi, Daniel,
Please see below.
On 6/4/20 10:12 AM, 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.
>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Jason Gunthorpe <jgg@...lanox.com>
> Cc: linux-mm@...ck.org
> Cc: linux-rdma@...r.kernel.org
> Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
> Cc: Christian König <christian.koenig@....com>
> Signed-off-by: Daniel Vetter <daniel.vetter@...el.com>
> ---
> This is part of a gpu lockdep annotation series simply because it
> really helps to catch issues where gpu subsystem locks and primitives
> can deadlock with themselves through allocations and mmu notifiers.
> But aside from that motivation it should be completely free-standing,
> and can land through -mm/-rdma/-hmm or any other tree really whenever.
> -Daniel
> ---
> mm/mmu_notifier.c | 7 -------
> mm/page_alloc.c | 23 ++++++++++++++---------
> 2 files changed, 14 insertions(+), 16 deletions(-)
>
> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> index 06852b896fa6..5d578b9122f8 100644
> --- a/mm/mmu_notifier.c
> +++ b/mm/mmu_notifier.c
> @@ -612,13 +612,6 @@ int __mmu_notifier_register(struct mmu_notifier *subscription,
> lockdep_assert_held_write(&mm->mmap_sem);
> BUG_ON(atomic_read(&mm->mm_users) <= 0);
>
> - if (IS_ENABLED(CONFIG_LOCKDEP)) {
> - fs_reclaim_acquire(GFP_KERNEL);
> - lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
> - lock_map_release(&__mmu_notifier_invalidate_range_start_map);
> - fs_reclaim_release(GFP_KERNEL);
> - }
> -
> if (!mm->notifier_subscriptions) {
> /*
> * kmalloc cannot be called under mm_take_all_locks(), but we
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 13cc653122b7..f8a222db4a53 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);
>
> @@ -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,23 @@ 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))
Hmm. Shouldn't this be "if (gfp_mask & __GFP_FS)" or am I misunderstanding?
> + __fs_reclaim_acquire();
#ifdef CONFIG_MMU_NOTIFIER?
> +
> + lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
> + lock_map_release(&__mmu_notifier_invalidate_range_start_map);
> +
> + }
> }
> EXPORT_SYMBOL_GPL(fs_reclaim_acquire);
>
> void fs_reclaim_release(gfp_t gfp_mask)
> {
> - if (__need_fs_reclaim(gfp_mask))
> - __fs_reclaim_release();
> + if (__need_reclaim(gfp_mask)) {
> + if (!(gfp_mask & __GFP_FS))
Same here?
> + __fs_reclaim_release();
> + }
> }
> EXPORT_SYMBOL_GPL(fs_reclaim_release);
> #endif
One suggested test case would perhaps be to call madvise(madv_dontneed)
on a subpart of a transhuge page. That would IIRC trigger a page split
and interesting mmu notifier calls....
Thanks,
Thomas
Powered by blists - more mailing lists