From: Peter Zijlstra <peterz@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
Avi Kivity <avi@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>, kvm <kvm@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: mmu_notifiers: turn off lockdep around mm_take_all_locks
Date: Tue, 07 Jul 2009 22:00:25 +0200 [thread overview]
Message-ID: <1246996825.5197.34.camel@laptop> (raw)
In-Reply-To: <alpine.LFD.2.01.0907071219170.3210@localhost.localdomain>
On Tue, 2009-07-07 at 12:25 -0700, Linus Torvalds wrote:
>
> On Tue, 7 Jul 2009, Peter Zijlstra wrote:
> >
> > Another issue, at about >=256 vmas we'll overflow the preempt count. So
> > disabling lockdep will only 'fix' this for a short while, until you've
> > bloated beyond that ;-)
>
> We would?
>
> I don't think so. Sure, we'd "overflow" into the softirq bits, but it's
> all designed to faile very gracefully. Somebody who tests our "status"
> might think we're in softirq context, but that really doesn't matter: we
> still have preemption disabled.
Right, it might confuse the softirq (and when we extend the vma limit
and go wild maybe the hardirq) state.
> > Linus, Ingo, any opinions?
>
> I do think that if lockdep can't handle it, we probably should turn it off
> around it.
>
> I don't think it's broken wrt regular preempt, though.
It does feel slightly weird to explicitly overflow that preempt count
though.
Hmm, the CONFIG_DEBUG_PREEMPT bits in kernel/sched.c
{sub,add}_preempt_count() will generate some splats though.
But sure, something like the below would disable lockdep for the
critical bits.. really don't like it though, but the alternative is
modifying the rmap locking and I don't like that either :/
---
mm/mmap.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 34579b2..cb7110e 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2400,6 +2400,7 @@ int mm_take_all_locks(struct mm_struct *mm)
mutex_lock(&mm_all_locks_mutex);
+ lockdep_off()
for (vma = mm->mmap; vma; vma = vma->vm_next) {
if (signal_pending(current))
goto out_unlock;
@@ -2417,6 +2418,8 @@ int mm_take_all_locks(struct mm_struct *mm)
ret = 0;
out_unlock:
+ lockdep_on();
+
if (ret)
mm_drop_all_locks(mm);
@@ -2470,12 +2473,14 @@ void mm_drop_all_locks(struct mm_struct *mm)
BUG_ON(down_read_trylock(&mm->mmap_sem));
BUG_ON(!mutex_is_locked(&mm_all_locks_mutex));
+ lockdep_off();
for (vma = mm->mmap; vma; vma = vma->vm_next) {
if (vma->anon_vma)
vm_unlock_anon_vma(vma->anon_vma);
if (vma->vm_file && vma->vm_file->f_mapping)
vm_unlock_mapping(vma->vm_file->f_mapping);
}
+ lockdep_on();
mutex_unlock(&mm_all_locks_mutex);
}
next prev parent reply other threads:[~2009-07-07 20:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-07 18:06 mmu_notifiers: turn off lockdep around mm_take_all_locks Marcelo Tosatti
2009-07-07 18:15 ` Peter Zijlstra
2009-07-07 18:18 ` Avi Kivity
2009-07-07 18:37 ` Marcelo Tosatti
2009-07-07 19:04 ` Peter Zijlstra
2009-07-07 19:25 ` Linus Torvalds
2009-07-07 20:00 ` Peter Zijlstra [this message]
2009-07-07 23:30 ` Andrea Arcangeli
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=1246996825.5197.34.camel@laptop \
--to=peterz@infradead.org \
--cc=aarcange@redhat.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mtosatti@redhat.com \
--cc=torvalds@linux-foundation.org \
/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