Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Mon, 11 Oct 1999 16:41:08 +0100 (BST) | Subject | Re: locking question: do_mmap(), do_munmap() |
| |
Hi,
On Sun, 10 Oct 1999 12:07:38 -0400 (EDT), Alexander Viro <viro@math.psu.edu> said:
>> eg. sys_mprotect calls merge_segments without lock_kernel().
> Manfred, Andrea - please stop it. Yes, it does and yes, it should. > Plonking the big lock around every access to VM is _not_ a solution. If > swapper doesn't use mmap_sem - _swapper_ should be fixed. How the hell > does lock_kernel() have smaller deadlock potential than > down(&mm->mmap_sem)?
The swapout code cannot claim the mmap semaphore. There are just too many deadlock possibilities. For example, the whole VM assumes that it is safe to try to allocate memory while holding the mmap semaphore. How are you going to make that work if we are short of immediately free pages and the allocation request recurses into the swapper?
The swapper has very strict requirements: to avoid blocking it requires the big lock and the page table spinlocks, so that it can survive without the mm semaphore. Adding the mm semaphore to the swapout loop is not really an option. That means that you need the kernel lock when modifying vma lists.
We can, however, improve things by using a per-mm spinlock instead of using the kernel lock to provide that guarantee.
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |