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 <a...@linux-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.