All of lore.kernel.org
 help / color / mirror / Atom feed
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);
 }



  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 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 \
    --subject='Re: mmu_notifiers: turn off lockdep around mm_take_all_locks' \
    /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

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.