linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ed L Cashin <ecashin@uga.edu>
To: Robert Love <rml@ximian.com>
Cc: linux-mm@kvack.org
Subject: Re: Documentation/vm/locking: why not hold two PT locks?
Date: Sun, 08 Feb 2004 16:47:13 -0500	[thread overview]
Message-ID: <87ekt5ckgu.fsf@cs.uga.edu> (raw)
In-Reply-To: <1076275778.5608.1.camel@localhost> (Robert Love's message of "Sun, 08 Feb 2004 16:29:38 -0500")

Robert Love <rml@ximian.com> writes:

> On Sun, 2004-02-08 at 16:18 -0500, Ed L Cashin wrote:
>
>> Hi.  Documentation/vm/locking says one must not simultaneously hold
>> the page table lock on mm A and mm B.  Is that true?  Where is the
>> danger?
>
> There isn't a proscribed lock ordering hierarchy, so you can deadlock.
>
> Assume thread 1 obtains the lock on mm A.
>
> Assume thread 2 obtains the lock on mm B.
>
> Assume thread 1 now obtains the lock on mm B - it is taken, so spin
> waiting.
>
> Assume thread 2 now obtains the lock on mm A - it too is taken, so spin
> waiting.
>
> Boom..

If that's all there is to it, then in my case, I have imposed a
locking hierarchy on my own code, so that wouldn't happen in my code.
I have a semaphore "S" outside of mmap_sem and page_table_lock.  Every
call path that can get to my code takes S before getting the
mmap_sem.  

  T1 gets S
  T1 gets mm A's mmap_sem
  T2 sleeps trying for S
  T1 gets A's PT lock
  T1 gets B's PT lock
  T1 clears a PTE in B 
  (I'd like to also be able to safely copy a PTE from B to A here)

  T1 puts B's PT lock
  T1 puts A's PT lock
  T1 puts A's mmap_sem
  T1 puts S

So it looks like my code is safe but not so efficient, since T2 has to
sleep when it doesn't get the semaphore S.  Is there some other
complication I'm missing?

-- 
--Ed L Cashin     PGP public key: http://noserose.net/e/pgp/

--
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:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2004-02-08 21:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-08 21:18 Ed L Cashin
2004-02-08 21:29 ` Robert Love
2004-02-08 21:47   ` Ed L Cashin [this message]
2004-02-08 22:12     ` Robert Love
2004-02-09  7:44       ` Kanoj Sarcar
2004-02-09 16:19         ` Ed L Cashin
2004-02-09 18:20           ` Kanoj Sarcar
2004-02-09 21:17             ` Ed L Cashin

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=87ekt5ckgu.fsf@cs.uga.edu \
    --to=ecashin@uga.edu \
    --cc=linux-mm@kvack.org \
    --cc=rml@ximian.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