From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: mhocko@kernel.org
Cc: akpm@linux-foundation.org, rientjes@google.com,
aarcange@redhat.com, benh@kernel.crashing.org, paulus@samba.org,
oded.gabbay@gmail.com, alexander.deucher@amd.com,
christian.koenig@amd.com, airlied@linux.ie, joro@8bytes.org,
dledford@redhat.com, jani.nikula@linux.intel.com,
mike.marciniszyn@intel.com, sean.hefty@intel.com,
sivanich@sgi.com, boris.ostrovsky@oracle.com, jglisse@redhat.com,
pbonzini@redhat.com, rkrcmar@redhat.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch v2 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks
Date: Sat, 16 Dec 2017 23:45:30 +0900 [thread overview]
Message-ID: <201712162345.BGD43248.FFOLJOFVQMHSOt@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <20171216113645.GG16951@dhcp22.suse.cz>
Michal Hocko wrote:
> On Sat 16-12-17 16:14:07, Tetsuo Handa wrote:
> > 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.
>
> Yes it cannot catch _all_ cases. This is an inherent problem of
> rwsem_is_locked because semaphores do not really have the owner concept.
> The core idea behind this, I guess, is to catch obviously incorrect
> usage and as such it gives us a reasonabe coverage. I could live without
> the annotation but rwsem_is_locked looks better than down_write_trylock
> to me.
I agree that rwsem_is_locked() is better than down_write_trylock() because
the former does not have side effect when nobody was holding the rwsem.
Looking at how rwsem_is_locked() is used in mm/ directory for sanity checks,
only VM_BUG_ON(), VM_BUG_ON_MM(), or VM_BUG_ON_VMA() are used. Therefore,
this WARN_ON_ONCE() usage might be irregular.
Also, regarding the problem that semaphores do not really have the owner
concept, we can add "struct task_struct *owner_of_mmap_sem_for_write" to
"struct mm_struct" and replace direct down_write_killable() etc. with
corresponding wrapper functions like
int __must_check get_mmap_sem_write_killable(struct mm_struct *mm) {
if (down_write_killable(&mm->mmap_sem))
return -EINTR;
mm->owner_of_mmap_sem_for_write = current;
return 0;
}
and make the rwsem_is_locked() test more robust by doing like
bool mmap_sem_is_held_for_write_by_current(struct mm_struct *mm) {
return mm->owner_of_mmap_sem_for_write == current;
}
. If there is a guarantee that no thread is allowed to hold multiple
mmap_sem, wrapper functions which manipulate per "struct task_struct"
flag will work.
But the fundamental problem is that we are heavily relying on runtime
testing (e.g. lockdep / syzkaller). Since there are a lot of factors which
prevent sanity checks from being called (e.g. conditional calls based on
threshold check), we can not exercise all paths, and everybody is making
changes without understanding all the dependencies. Consider that nobody
noticed that relying on __GFP_DIRECT_RECLAIM with oom_lock held may cause
lockups. We are too easily introducing unsafe dependency. I think that we
need to describe all the dependencies without relying on runtime testing.
Back to MMU_INVALIDATE_DOES_NOT_BLOCK flag, I worry that we will fail to
notice when somebody in future makes changes with mmu notifier which
currently does not rely on __GFP_DIRECT_RECLAIM to by error rely on
__GFP_DIRECT_RECLAIM. Staying at "whether the callback might sleep"
granularity will help preventing such unnoticed dependency bugs from
being introduced.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-12-16 14:45 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-11 22:11 [patch " David Rientjes
2017-12-11 22:11 ` [patch 2/2] mm, oom: avoid reaping only for mm's " David Rientjes
2017-12-11 22:23 ` [patch 1/2] mm, mmu_notifier: annotate mmu notifiers " Paolo Bonzini
2017-12-11 23:09 ` David Rientjes
2017-12-12 20:05 ` Dimitri Sivanich
2017-12-12 21:28 ` David Rientjes
2017-12-13 9:34 ` Christian König
2017-12-13 10:26 ` Tetsuo Handa
2017-12-13 10:37 ` Paolo Bonzini
2017-12-14 9:19 ` David Rientjes
2017-12-14 12:46 ` kbuild test robot
2017-12-14 21:30 ` [patch v2 " David Rientjes
2017-12-14 21:31 ` [patch v2 2/2] mm, oom: avoid reaping only for mm's " David Rientjes
2017-12-15 16:35 ` Michal Hocko
2017-12-15 21:46 ` David Rientjes
2017-12-15 8:42 ` [patch v2 1/2] mm, mmu_notifier: annotate mmu notifiers " Paolo Bonzini
2017-12-15 12:19 ` Christian König
2017-12-15 13:36 ` Dimitri Sivanich
2017-12-15 16:25 ` Michal Hocko
2017-12-16 6:21 ` Tetsuo Handa
2017-12-16 11:33 ` Michal Hocko
2017-12-15 23:04 ` Andrew Morton
2017-12-16 7:14 ` Tetsuo Handa
2017-12-16 11:36 ` Michal Hocko
2017-12-16 14:45 ` Tetsuo Handa [this message]
2017-12-16 9:10 ` Michal Hocko
2018-01-09 21:40 ` [patch -mm] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks fix fix David Rientjes
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=201712162345.BGD43248.FFOLJOFVQMHSOt@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=aarcange@redhat.com \
--cc=airlied@linux.ie \
--cc=akpm@linux-foundation.org \
--cc=alexander.deucher@amd.com \
--cc=benh@kernel.crashing.org \
--cc=boris.ostrovsky@oracle.com \
--cc=christian.koenig@amd.com \
--cc=dledford@redhat.com \
--cc=jani.nikula@linux.intel.com \
--cc=jglisse@redhat.com \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mike.marciniszyn@intel.com \
--cc=oded.gabbay@gmail.com \
--cc=paulus@samba.org \
--cc=pbonzini@redhat.com \
--cc=rientjes@google.com \
--cc=rkrcmar@redhat.com \
--cc=sean.hefty@intel.com \
--cc=sivanich@sgi.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: 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