public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>, Ingo Molnar <mingo@elte.hu>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: How to avoid spurious lockdep warnings?
Date: Thu, 20 Mar 2008 16:02:11 -0700	[thread overview]
Message-ID: <47E2ECF3.2050606@goop.org> (raw)

In a Xen system, when a new pagetable is about to be put in use it is 
"pinned", meaning that each page in the pagetable is registered with the 
hypervisor.  This is done in arch/x86/xen/mmu.c:pin_page().

In order to make this efficient, the hypercalls for pinning are batched, 
so that multiple pages are submitted at once in a single multicall.  
While a page is batched pending the hypercall, its corresponding 
pte_lock is held.

This means that the code can end up holding multiple pte locks at once, 
though it is guaranteed to never try to hold the same lock at once.  
However, because these locks are in the same lock class, I get a 
spurious warning from lockdep.  Is there some way I can get rid of this 
warning?

=============================================
[ INFO: possible recursive locking detected ]
2.6.25-rc6-x86-latest.git-dirty #297
---------------------------------------------
init/1 is trying to acquire lock:
 (__pte_lockptr(page)){--..}, at: [<c0105038>] pin_page+0x6a/0x167

but task is already holding lock:
 (__pte_lockptr(page)){--..}, at: [<c0105038>] pin_page+0x6a/0x167

other info that might help us debug this:
4 locks held by init/1:
 #0:  (&mm->mmap_sem){----}, at: [<c012645c>] copy_process+0x97e/0x122f
 #1:  (&mm->mmap_sem/1){--..}, at: [<c012646c>] copy_process+0x98e/0x122f
 #2:  (&mm->page_table_lock){--..}, at: [<c0104bf5>] xen_dup_mmap+0x11/0x24
 #3:  (__pte_lockptr(page)){--..}, at: [<c0105038>] pin_page+0x6a/0x167

stack backtrace:
Pid: 1, comm: init Not tainted 2.6.25-rc6-x86-latest.git-dirty #297
 [<c0144049>] __lock_acquire+0x821/0xb50
 [<c01443ee>] lock_acquire+0x76/0x9d
 [<c0105038>] ? pin_page+0x6a/0x167
 [<c0454537>] _spin_lock+0x23/0x32
 [<c0105038>] ? pin_page+0x6a/0x167
 [<c0105038>] pin_page+0x6a/0x167
 [<c0104520>] pgd_walk+0x18f/0x1e1
 [<c0104fce>] ? pin_page+0x0/0x167
 [<c0104b20>] xen_pgd_pin+0x46/0x10a
 [<c0104bfd>] xen_dup_mmap+0x19/0x24
 [<c0126619>] copy_process+0xb3b/0x122f
 [<c0126e6d>] do_fork+0xab/0x1dd
 [<c017341b>] ? vfs_write+0xf1/0x108
 [<c010877a>] ? sysenter_past_esp+0xba/0xc8
 [<c0106cd5>] sys_clone+0x1f/0x21
 [<c0108731>] sysenter_past_esp+0x71/0xc8
 =======================


Thanks,
    J

             reply	other threads:[~2008-03-20 23:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-20 23:02 Jeremy Fitzhardinge [this message]
2008-03-20 23:44 ` How to avoid spurious lockdep warnings? Peter Zijlstra
2008-03-21  5:35   ` Jeremy Fitzhardinge
2008-03-22 20:46 ` Arjan van de Ven
2008-03-22 21:08   ` Jeremy Fitzhardinge

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=47E2ECF3.2050606@goop.org \
    --to=jeremy@goop.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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