linux.git/arch/powerpc/kernel/process.c, branch v2.6.15

powerpc: Fix bug causing FP registers corruption on UP + preempt

2005-11-30T02:20:54+00:00

This fixes a bug noticed by Paolo Galtieri and fixed for ARCH=ppc in
the previous commit (ppc: fix floating point register corruption).
This fixes the arch/powerpc code by adding preempt_disable/enable,
and also cleans it up a bit by pulling out the code that discards
any lazily-switched CPU register state into a new function, rather
than having that code repeated in three places.

Signed-off-by: Paul Mackerras

[PATCH] kprobes: Fix return probes on sys_execve

2005-11-24T00:08:39+00:00

Fix a bug in kprobes that can cause an Oops or even a crash when a return
probe is installed on one of the following functions: sys_execve,
do_execve, load_*_binary, flush_old_exec, or flush_thread.  The fix is to
remove the call to kprobe_flush_task() in flush_thread().  This fix has
been tested on all architectures for which the return-probes feature has
been implemented (i386, x86_64, ppc64, ia64).  Please apply.

BACKGROUND

Up to now, we have called kprobe_flush_task() under two situations: when a
task exits, and when it execs.  Flushing kretprobe_instances on exit is
correct because (a) do_exit() doesn't return, and (b) one or more
return-probed functions may be active when a task calls do_exit().  Neither
is the case for sys_execve() and its callees.

Initially, the mistaken call to kprobe_flush_task() on exec was harmless
because we put the "real" return address of each active probed function
back in the stack, just to be safe, when we recycled its
kretprobe_instance.  When support for ppc64 and ia64 was added, this safety
measure couldn't be employed, and was eventually dropped even for i386 and
x86_64.  sys_execve() and its callees were informally blacklisted for
return probes until this fix was developed.

Acked-by: Prasanna S Panchamukhi 
Signed-off-by: Jim Keniston 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge ../linux-2.6

2005-11-07T03:42:09+00:00

[PATCH] powerpc: Make ppc_md.set_dabr non 64-bit specific

2005-11-07T02:31:13+00:00

Define ppc_md.set_dabr for both 32 + 64 bit. Cleanup the implementation for
pSeries also, it was needlessly complex. Now we just do two firmware tests at
setup time, and use one of two functions, rather than using one function and
testing on every call.

Signed-off-by: Michael Ellerman 
Signed-off-by: Paul Mackerras

[PATCH] ppc64: support 64k pages

2005-11-07T00:56:47+00:00

Adds a new CONFIG_PPC_64K_PAGES which, when enabled, changes the kernel
base page size to 64K.  The resulting kernel still boots on any
hardware.  On current machines with 4K pages support only, the kernel
will maintain 16 "subpages" for each 64K page transparently.

Note that while real 64K capable HW has been tested, the current patch
will not enable it yet as such hardware is not released yet, and I'm
still verifying with the firmware architects the proper to get the
information from the newer hypervisors.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Linus Torvalds

powerpc: Make set_dabr() a ppc_md function

2005-11-03T04:30:49+00:00

Move pSeries specific code in set_dabr() into a ppc_md function, this will
allow us to keep plpar_wrappers.h private to platforms/pseries.

Signed-off-by: Michael Ellerman

[PATCH] powerpc: Fix handling of fpscr on 64-bit

2005-10-27T10:48:50+00:00

The recent merge of fpu.S broken the handling of fpscr for
ARCH=powerpc and CONFIG_PPC64=y.  FP registers could be corrupted,
leading to strange random application crashes.

The confusion arises, because the thread_struct has (and requires) a
64-bit area to save the fpscr, because we use load/store double
instructions to get it in to/out of the FPU.  However, only the low
32-bits are actually used, so we want to treat it as a 32-bit quantity
when manipulating its bits to avoid extra load/stores on 32-bit.  This
patch replaces the current definition with a structure of two 32-bit
quantities (pad and val), to clarify things as much as is possible.
The 'val' field is used when manipulating bits, the structure itself
is used when obtaining the address for loading/unloading the value
from the FPU.

While we're at it, consolidate the 4 (!) almost identical versions of
cvt_fd() and cvt_df() (arch/ppc/kernel/misc.S,
arch/ppc64/kernel/misc.S, arch/powerpc/kernel/misc_32.S,
arch/powerpc/kernel/misc_64.S) into a single version in fpu.S.  The
new version takes a pointer to thread_struct and applies the correct
offset itself, rather than a pointer to the fpscr field itself, again
to avoid confusion as to which is the correct field to use.

Finally, this patch makes ARCH=ppc64 also use the consolidated fpu.S
code, which it previously did not.

Built for G5 (ARCH=ppc64 and ARCH=powerpc), 32-bit powermac (ARCH=ppc
and ARCH=powerpc) and Walnut (ARCH=ppc, CONFIG_MATH_EMULATION=y).
Booted on G5 (ARCH=powerpc) and things which previously fell over no
longer do.

Signed-off-by: David Gibson 
Signed-off-by: Paul Mackerras

[PATCH] powerpc: Don't blow away load_addr in start_thread

2005-10-21T12:47:39+00:00

The patch to make process.c work for 32-bit and 64-bit
(06d67d54741a5bfefa31945ef195dfa748c29025) broke some 64-bit binaries.
We were blowing away load_addr in gpr[2], so we weren't properly relocating
the entry point.

Signed-off-by: Michael Ellerman 
Signed-off-by: Paul Mackerras

ppc64: merge binfmt_elf32.c

2005-10-13T03:40:54+00:00

and use start_thread for both 32 and 64 bit bineries.

Signed-off-by: Stephen Rothwell

powerpc: make 64 bit binaries work

2005-10-12T23:49:56+00:00

Signed-off-by: Stephen Rothwell