Re: Deadlock on the mm->mmap_sem

From: Linus Torvalds (torvalds@transmeta.com)
Date: Mon Sep 17 2001 - 18:39:05 EST


[ David, Andrea - can you check this out? ]

In article <001701c13fc2$cda19a90$010411ac@local>,
Manfred Spraul <manfred@colorfullife.com> wrote:
>> What happens is that proc_pid_read_maps grabs the mmap_sem as a
>> reader, and *while it holds the lock*, does a copy_to_user. This can
>> of course page-fault, and the handler will also grab the mmap_sem
>> (if it is the same task).
>
>Ok, that's a bug.
>You must not call copy_to_user with the mmap semaphore acquired - linux
>semaphores are not recursive.

No, that's not the bug.

The mmap semaphore is a read-write semaphore, and it _is_ permissible to
call "copy_to_user()" and friends while holding the read lock.

The bug appears to be in the implementation of the write semaphore -
down_write() doesn't undestand that blocked writes must not block new
readers, exactly because of this situation.

The situation wrt read-write spinlocks is exactly the same, btw, except
there we have "readers can have interrupts enabled even if interrupts
also take read locks" instead of having user-level faults.

Why do we want to explicitly allow this behaviour wrt mmap_sem? Because
some things are inherently racy without it (ie threaded processes that
read or write the address space - coredumping, ptrace etc).

                Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Sep 23 2001 - 21:00:22 EST