summaryrefslogtreecommitdiff
path: root/arch/xtensa
diff options
context:
space:
mode:
authorHugh Dickins <hugh@veritas.com>2006-12-10 02:18:43 -0800
committerLinus Torvalds <torvalds@woody.osdl.org>2006-12-10 09:55:39 -0800
commit5fcf7bb73f66cc1c4ad90788b0f367c4d6852b75 (patch)
tree76854ba1babc308beaf8f19d299a5b32ab7fda30 /arch/xtensa
parent347a00fb4ad2200f8f8331f8b366b1d84eff577d (diff)
downloadlinux-stable-5fcf7bb73f66cc1c4ad90788b0f367c4d6852b75.tar.gz
linux-stable-5fcf7bb73f66cc1c4ad90788b0f367c4d6852b75.tar.bz2
linux-stable-5fcf7bb73f66cc1c4ad90788b0f367c4d6852b75.zip
[PATCH] read_zero_pagealigned() locking fix
Ramiro Voicu hits the BUG_ON(!pte_none(*pte)) in zeromap_pte_range: kernel bugzilla 7645. Right: read_zero_pagealigned uses down_read of mmap_sem, but another thread's racing read of /dev/zero, or a normal fault, can easily set that pte again, in between zap_page_range and zeromap_page_range getting there. It's been wrong ever since 2.4.3. The simple fix is to use down_write instead, but that would serialize reads of /dev/zero more than at present: perhaps some app would be badly affected. So instead let zeromap_page_range return the error instead of BUG_ON, and read_zero_pagealigned break to the slower clear_user loop in that case - there's no need to optimize for it. Use -EEXIST for when a pte is found: BUG_ON in mmap_zero (the other user of zeromap_page_range), though it really isn't interesting there. And since mmap_zero wants -EAGAIN for out-of-memory, the zeromaps better return that than -ENOMEM. Signed-off-by: Hugh Dickins <hugh@veritas.com> Cc: Ramiro Voicu: <Ramiro.Voicu@cern.ch> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'arch/xtensa')
0 files changed, 0 insertions, 0 deletions