From: "Koenig, Christian" <Christian.Koenig@amd.com> To: Daniel Vetter <daniel.vetter@ffwll.ch>, LKML <linux-kernel@vger.kernel.org> Cc: "Linux MM" <linux-mm@kvack.org>, "Intel Graphics Development" <intel-gfx@lists.freedesktop.org>, "DRI Development" <dri-devel@lists.freedesktop.org>, "Andrew Morton" <akpm@linux-foundation.org>, "Michal Hocko" <mhocko@suse.com>, "David Rientjes" <rientjes@google.com>, "Jérôme Glisse" <jglisse@redhat.com>, "Daniel Vetter" <daniel.vetter@intel.com> Subject: Re: [PATCH 2/3] mm, notifier: Catch sleeping/blocking for !blockable Date: Thu, 22 Nov 2018 18:55:17 +0000 [thread overview] Message-ID: <f9c39a9a-5afd-4aed-c9ad-0c3fef34a449@amd.com> (raw) In-Reply-To: <20181122165106.18238-3-daniel.vetter@ffwll.ch> Am 22.11.18 um 17:51 schrieb Daniel Vetter: > We need to make sure implementations don't cheat and don't have a > possible schedule/blocking point deeply burried where review can't > catch it. > > I'm not sure whether this is the best way to make sure all the > might_sleep() callsites trigger, and it's a bit ugly in the code flow. > But it gets the job done. > > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Michal Hocko <mhocko@suse.com> > Cc: David Rientjes <rientjes@google.com> > Cc: "Christian König" <christian.koenig@amd.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: "Jérôme Glisse" <jglisse@redhat.com> > Cc: linux-mm@kvack.org > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > --- > mm/mmu_notifier.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c > index 59e102589a25..4d282cfb296e 100644 > --- a/mm/mmu_notifier.c > +++ b/mm/mmu_notifier.c > @@ -185,7 +185,13 @@ int __mmu_notifier_invalidate_range_start(struct mm_struct *mm, > id = srcu_read_lock(&srcu); > hlist_for_each_entry_rcu(mn, &mm->mmu_notifier_mm->list, hlist) { > if (mn->ops->invalidate_range_start) { > - int _ret = mn->ops->invalidate_range_start(mn, mm, start, end, blockable); > + int _ret; > + > + if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP) && !blockable) > + preempt_disable(); > + _ret = mn->ops->invalidate_range_start(mn, mm, start, end, blockable); > + if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP) && !blockable) > + preempt_enable(); Just for the sake of better documenting this how about adding this to include/linux/kernel.h right next to might_sleep(): #define disallow_sleeping_if(cond) for((cond) ? preempt_disable() : (void)0; (cond); preempt_disable()) (Just from the back of my head, might contain peanuts and/or hints of errors). Christian. > if (_ret) { > pr_info("%pS callback failed with %d in %sblockable context.\n", > mn->ops->invalidate_range_start, _ret,
WARNING: multiple messages have this Message-ID (diff)
From: "Koenig, Christian" <Christian.Koenig@amd.com> To: Daniel Vetter <daniel.vetter@ffwll.ch>, LKML <linux-kernel@vger.kernel.org> Cc: "Michal Hocko" <mhocko@suse.com>, "Intel Graphics Development" <intel-gfx@lists.freedesktop.org>, "DRI Development" <dri-devel@lists.freedesktop.org>, "Linux MM" <linux-mm@kvack.org>, "Jérôme Glisse" <jglisse@redhat.com>, "David Rientjes" <rientjes@google.com>, "Daniel Vetter" <daniel.vetter@intel.com>, "Andrew Morton" <akpm@linux-foundation.org> Subject: Re: [PATCH 2/3] mm, notifier: Catch sleeping/blocking for !blockable Date: Thu, 22 Nov 2018 18:55:17 +0000 [thread overview] Message-ID: <f9c39a9a-5afd-4aed-c9ad-0c3fef34a449@amd.com> (raw) In-Reply-To: <20181122165106.18238-3-daniel.vetter@ffwll.ch> Am 22.11.18 um 17:51 schrieb Daniel Vetter: > We need to make sure implementations don't cheat and don't have a > possible schedule/blocking point deeply burried where review can't > catch it. > > I'm not sure whether this is the best way to make sure all the > might_sleep() callsites trigger, and it's a bit ugly in the code flow. > But it gets the job done. > > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Michal Hocko <mhocko@suse.com> > Cc: David Rientjes <rientjes@google.com> > Cc: "Christian König" <christian.koenig@amd.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: "Jérôme Glisse" <jglisse@redhat.com> > Cc: linux-mm@kvack.org > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > --- > mm/mmu_notifier.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c > index 59e102589a25..4d282cfb296e 100644 > --- a/mm/mmu_notifier.c > +++ b/mm/mmu_notifier.c > @@ -185,7 +185,13 @@ int __mmu_notifier_invalidate_range_start(struct mm_struct *mm, > id = srcu_read_lock(&srcu); > hlist_for_each_entry_rcu(mn, &mm->mmu_notifier_mm->list, hlist) { > if (mn->ops->invalidate_range_start) { > - int _ret = mn->ops->invalidate_range_start(mn, mm, start, end, blockable); > + int _ret; > + > + if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP) && !blockable) > + preempt_disable(); > + _ret = mn->ops->invalidate_range_start(mn, mm, start, end, blockable); > + if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP) && !blockable) > + preempt_enable(); Just for the sake of better documenting this how about adding this to include/linux/kernel.h right next to might_sleep(): #define disallow_sleeping_if(cond) for((cond) ? preempt_disable() : (void)0; (cond); preempt_disable()) (Just from the back of my head, might contain peanuts and/or hints of errors). Christian. > if (_ret) { > pr_info("%pS callback failed with %d in %sblockable context.\n", > mn->ops->invalidate_range_start, _ret, _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-11-22 18:55 UTC|newest] Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-22 16:51 [PATCH 0/3] RFC: mmu notifier debug checks Daniel Vetter 2018-11-22 16:51 ` [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail Daniel Vetter 2018-11-22 16:53 ` [Intel-gfx] " Chris Wilson 2018-11-22 16:53 ` Chris Wilson 2018-11-22 16:53 ` [Intel-gfx] " Chris Wilson 2018-11-23 8:49 ` Daniel Vetter 2018-11-23 11:14 ` Michal Hocko 2018-11-22 18:50 ` Koenig, Christian 2018-11-22 18:50 ` Koenig, Christian 2018-11-23 11:15 ` Michal Hocko 2018-11-23 11:15 ` Michal Hocko 2018-11-23 11:15 ` Michal Hocko 2018-11-23 12:30 ` Daniel Vetter 2018-11-23 12:30 ` Daniel Vetter 2018-11-23 12:30 ` Daniel Vetter 2018-11-23 12:43 ` Michal Hocko 2018-11-23 13:15 ` Daniel Vetter 2018-11-23 13:15 ` Daniel Vetter 2018-11-23 13:30 ` Michal Hocko 2018-11-22 16:51 ` [PATCH 2/3] mm, notifier: Catch sleeping/blocking for !blockable Daniel Vetter 2018-11-22 18:55 ` Koenig, Christian [this message] 2018-11-22 18:55 ` Koenig, Christian 2018-11-23 8:46 ` Daniel Vetter 2018-11-23 8:46 ` Daniel Vetter 2018-11-23 8:46 ` Daniel Vetter 2018-11-23 10:14 ` Christian König 2018-11-23 11:12 ` Michal Hocko 2018-11-23 11:12 ` Michal Hocko 2018-11-23 12:38 ` Daniel Vetter 2018-11-23 12:38 ` Daniel Vetter 2018-11-23 12:46 ` Michal Hocko 2018-11-23 13:12 ` Daniel Vetter 2018-11-23 13:12 ` Daniel Vetter 2018-11-23 13:23 ` [Intel-gfx] " Tvrtko Ursulin 2018-11-22 16:51 ` [PATCH 3/3] mm, notifier: Add a lockdep map for invalidate_range_start Daniel Vetter 2018-11-22 16:51 ` Daniel Vetter 2018-11-27 7:49 ` Daniel Vetter 2018-11-27 7:49 ` Daniel Vetter 2018-11-27 7:49 ` Daniel Vetter 2018-11-27 16:49 ` [Intel-gfx] " Chris Wilson 2018-11-27 16:49 ` Chris Wilson 2018-11-27 17:28 ` Daniel Vetter 2018-11-27 17:28 ` Daniel Vetter 2018-11-27 17:33 ` [Intel-gfx] " Chris Wilson 2018-11-27 17:33 ` Chris Wilson 2018-11-27 17:39 ` [Intel-gfx] " Daniel Vetter 2018-11-27 17:39 ` Daniel Vetter 2018-11-27 17:39 ` Daniel Vetter 2018-11-22 18:09 ` ✗ Fi.CI.CHECKPATCH: warning for RFC: mmu notifier debug checks Patchwork 2018-11-22 18:26 ` ✓ Fi.CI.BAT: success " Patchwork 2018-11-23 0:27 ` ✗ Fi.CI.IGT: failure " Patchwork
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=f9c39a9a-5afd-4aed-c9ad-0c3fef34a449@amd.com \ --to=christian.koenig@amd.com \ --cc=akpm@linux-foundation.org \ --cc=daniel.vetter@ffwll.ch \ --cc=daniel.vetter@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=jglisse@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@suse.com \ --cc=rientjes@google.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.