aboutsummaryrefslogtreecommitdiff
path: root/arch/sparc64
diff options
context:
space:
mode:
authorHugh Dickins <hugh@veritas.com>2007-03-09 08:42:48 +0100
committerAdrian Bunk <bunk@stusta.de>2007-03-09 08:42:48 +0100
commit0096623513107562ede3254df8d50d86474e5a7a (patch)
tree51cca0f0d4fe15e6e806133070fd739d75755a1f /arch/sparc64
parent90aab35b1626fce37326ea18cc54d7ff5ffa5ab6 (diff)
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: Adrian Bunk <bunk@stusta.de>
Diffstat (limited to 'arch/sparc64')
0 files changed, 0 insertions, 0 deletions