| commit | 7ee78232501ea9de2b6c8f10d32c9a0fee541357 | |
| author | Hugh Dickins <hugh@veritas.com> | |
| Sun, 30 Oct 2005 01:16:08 +0000 (29 18:16 -0700) | ||
| committer | Linus Torvalds <torvalds@g5.osdl.org> | |
| Sun, 30 Oct 2005 04:40:38 +0000 (29 21:40 -0700) | ||
| tree | 2041a36a13bdd8b096dfbf52b63a87739ea97d6b | treesnapshot (tar.gz zip) |
| parent | fd3e42fcc888a773572282575d2fdbf5cfd6216e | commitdiff |
[PATCH] mm: dup_mmap down new mmap_sem
One anomaly remains from when Andrea rationalized the responsibilities of
mmap_sem and page_table_lock: in dup_mmap we add vmas to the child holding its
page_table_lock, but not the mmap_sem which normally guards the vma list and
rbtree. Which could be an issue for unuse_mm: though since it just walks down
the list (today with page_table_lock, tomorrow not), it's probably okay. Will
need a memory barrier? Oh, keep it simple, Nick and I agreed, no harm in
taking child's mmap_sem here.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
One anomaly remains from when Andrea rationalized the responsibilities of
mmap_sem and page_table_lock: in dup_mmap we add vmas to the child holding its
page_table_lock, but not the mmap_sem which normally guards the vma list and
rbtree. Which could be an issue for unuse_mm: though since it just walks down
the list (today with page_table_lock, tomorrow not), it's probably okay. Will
need a memory barrier? Oh, keep it simple, Nick and I agreed, no harm in
taking child's mmap_sem here.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
| kernel/fork.c | diffblobblamehistory |