futex: setup writeable mapping for futex ops which modify user space data
authorThomas Gleixner <tglx@linutronix.de>
Mon, 18 May 2009 19:20:10 +0000 (21:20 +0200)
committerThomas Gleixner <tglx@linutronix.de>
Tue, 19 May 2009 21:36:52 +0000 (23:36 +0200)
commit64d1304a64477629cb16b75491a77bafe6f86963
treef9bf95141429174d3e4596d3c4f5b167b6c0e745
parent279e677faa775ad16e75c32e1bf4a37f8158bc61
futex: setup writeable mapping for futex ops which modify user space data

The futex code installs a read only mapping via get_user_pages_fast()
even if the futex op function has to modify user space data. The
eventual fault was fixed up by futex_handle_fault() which walked the
VMA with mmap_sem held.

After the cleanup patches which removed the mmap_sem dependency of the
futex code commit 4dc5b7a36a49eff97050894cf1b3a9a02523717 (futex:
clean up fault logic) removed the private VMA walk logic from the
futex code. This change results in a stale RO mapping which is not
fixed up.

Instead of reintroducing the previous fault logic we set up the
mapping in get_user_pages_fast() read/write for all operations which
modify user space data. Also handle private futexes in the same way
and make the current unconditional access_ok(VERIFY_WRITE) depend on
the futex op.

Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
CC: stable@kernel.org
kernel/futex.c