[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cafa6cdb-886b-b010-753f-600ae86f5e71@I-love.SAKURA.ne.jp>
Date: Sat, 16 Dec 2017 16:14:07 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Andrew Morton <akpm@...ux-foundation.org>,
David Rientjes <rientjes@...gle.com>
Cc: Michal Hocko <mhocko@...e.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Oded Gabbay <oded.gabbay@...il.com>,
Alex Deucher <alexander.deucher@....com>,
Christian König <christian.koenig@....com>,
David Airlie <airlied@...ux.ie>,
Joerg Roedel <joro@...tes.org>,
Doug Ledford <dledford@...hat.com>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Mike Marciniszyn <mike.marciniszyn@...el.com>,
Sean Hefty <sean.hefty@...el.com>,
Dimitri Sivanich <sivanich@....com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Jérôme Glisse <jglisse@...hat.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [patch v2 1/2] mm, mmu_notifier: annotate mmu notifiers with
blockable invalidate callbacks
On 2017/12/16 8:04, Andrew Morton wrote:
>> The implementation is steered toward an expensive slowpath, such as after
>> the oom reaper has grabbed mm->mmap_sem of a still alive oom victim.
>
> some tweakage, please review.
>
> From: Andrew Morton <akpm@...ux-foundation.org>
> Subject: mm-mmu_notifier-annotate-mmu-notifiers-with-blockable-invalidate-callbacks-fix
>
> make mm_has_blockable_invalidate_notifiers() return bool, use rwsem_is_locked()
>
> @@ -240,13 +240,13 @@ EXPORT_SYMBOL_GPL(__mmu_notifier_invalid
> * Must be called while holding mm->mmap_sem for either read or write.
> * The result is guaranteed to be valid until mm->mmap_sem is dropped.
> */
> -int mm_has_blockable_invalidate_notifiers(struct mm_struct *mm)
> +bool mm_has_blockable_invalidate_notifiers(struct mm_struct *mm)
> {
> struct mmu_notifier *mn;
> int id;
> - int ret = 0;
> + bool ret = false;
>
> - WARN_ON_ONCE(down_write_trylock(&mm->mmap_sem));
> + WARN_ON_ONCE(!rwsem_is_locked(&mm->mmap_sem));
>
> if (!mm_has_notifiers(mm))
> return ret;
rwsem_is_locked() test isn't equivalent with __mutex_owner() == current test, is it?
If rwsem_is_locked() returns true because somebody else has locked it, there is
no guarantee that current thread has locked it before calling this function.
down_write_trylock() test isn't equivalent with __mutex_owner() == current test, is it?
What if somebody else held it for read or write (the worst case is registration path),
down_write_trylock() will return false even if current thread has not locked it for
read or write.
I think this WARN_ON_ONCE() can not detect incorrect call to this function.
Powered by blists - more mailing lists