make ppc64 current preempt-safe
commitf102c840f7f72492a83c93fa65396fe0edcf1df6
authorHugh Dickins <hugh@veritas.com>
Thu, 4 Jan 2007 20:26:22 +0000 (4 20:26 +0000)
committerGreg Kroah-Hartman <gregkh@suse.de>
Fri, 23 Feb 2007 23:49:53 +0000 (23 15:49 -0800)
tree3920462d52467e8c2a4baf2fd5938aa93e35108f
parent700019f9fea4d78100e0b6032db3a66040620d42
make ppc64 current preempt-safe

Repeated -j20 kernel builds on a G5 Quad running an SMP PREEMPT kernel
would often collapse within a day, some exec failing with "Bad address".
In each case examined, load_elf_binary was doing a kernel_read, but
generic_file_aio_read's access_ok saw current->thread.fs.seg as USER_DS
instead of KERNEL_DS.

objdump of filemap.o shows gcc 4.1.0 emitting "mr r5,r13 ... ld r9,416(r5)"
here for get_paca()->__current, instead of the expected and much more usual
"ld r9,416(r13)"; I've seen other gcc4s do the same, but perhaps not gcc3s.

So, if the task is preempted and rescheduled on a different cpu in between
the mr and the ld, r5 will be looking at a different paca_struct from the
one it's now on, pick up the wrong __current, and perhaps the wrong seg.
Presumably much worse could happen elsewhere, though that split is rare.

Other architectures appear to be safe (x86_64's read_pda is more limiting
than get_paca), but ppc64 needs to force "current" into one instruction.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
include/asm-powerpc/current.h