lkml.org 
[lkml]   [2001]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Deadlock on the mm->mmap_sem
Date
[ 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/

\
 
 \ /
  Last update: 2005-03-22 13:03    [W:0.385 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site