summaryrefslogtreecommitdiffstats
path: root/kernel/trace
diff options
context:
space:
mode:
authorThomas Gleixner <tglx@linutronix.de>2009-05-18 21:20:10 +0200
committerThomas Gleixner <tglx@linutronix.de>2009-05-19 23:36:52 +0200
commit64d1304a64477629cb16b75491a77bafe6f86963 (patch)
treef9bf95141429174d3e4596d3c4f5b167b6c0e745 /kernel/trace
parentMerge branch 'fixes-for-linus' of git://git.monstr.eu/linux-2.6-microblaze (diff)
downloadlinux-64d1304a64477629cb16b75491a77bafe6f86963.tar.xz
linux-64d1304a64477629cb16b75491a77bafe6f86963.zip
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
Diffstat (limited to 'kernel/trace')
0 files changed, 0 insertions, 0 deletions