diff options
author | Hugh Dickins <hugh@veritas.com> | 2008-12-10 20:48:52 +0000 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2008-12-10 14:40:45 -0800 |
commit | b88ed20594db2c685555b68c52b693b75738b2f5 (patch) | |
tree | a8edcf975fb8437692bf670841859d4ac9fbd2f0 /kernel/pid_namespace.c | |
parent | f4fd2c5b6f691ff71614acbc28461b3c1488c81b (diff) |
fix mapping_writably_mapped()
Lee Schermerhorn noticed yesterday that I broke the mapping_writably_mapped
test in 2.6.7! Bad bad bug, good good find.
The i_mmap_writable count must be incremented for VM_SHARED (just as
i_writecount is for VM_DENYWRITE, but while holding the i_mmap_lock)
when dup_mmap() copies the vma for fork: it has its own more optimal
version of __vma_link_file(), and I missed this out. So the count
was later going down to 0 (dangerous) when one end unmapped, then
wrapping negative (inefficient) when the other end unmapped.
The only impact on x86 would have been that setting a mandatory lock on
a file which has at some time been opened O_RDWR and mapped MAP_SHARED
(but not necessarily PROT_WRITE) across a fork, might fail with -EAGAIN
when it should succeed, or succeed when it should fail.
But those architectures which rely on flush_dcache_page() to flush
userspace modifications back into the page before the kernel reads it,
may in some cases have skipped the flush after such a fork - though any
repetitive test will soon wrap the count negative, in which case it will
flush_dcache_page() unnecessarily.
Fix would be a two-liner, but mapping variable added, and comment moved.
Reported-by: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'kernel/pid_namespace.c')
0 files changed, 0 insertions, 0 deletions