Re: Documentation/vm/locking: why not hold two PT locks?

Ed L Cashin
2004-02-08T21:47:13Z

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/