litmus2008.git/arch/ppc/kernel, branch master

sysctl: kill binary sysctl KERN_PPC_L2CR

2008-01-24T16:07:27+00:00

: Stefan Roese  said:
> ppc: 4xx: sysctl table check failed: /kernel/l2cr .1.31 Missing strategy
>
> I'm seeing this error message when booting an recent arch/ppc kernel on
> 4xx platforms (tested on Ocotea and other 4xx platforms). Booting NFS
> rootfs still works fine, but this message kind of makes me "nervous".
> This is not seen on 4xx arch/powerpc platforms. Here the bootlog:

Because the data field was never filled and a binary sysctl handler was
never written this sysctl has never been usable through the sys_sysctl
interface.  So just remove the binary sysctl number.  Making the kernel
sanity checks happy.

Signed-off-by: Eric W. Biederman 
Reported-by: Stefan Roese 
Cc: Josh Boyer 
Cc: Wolfgang Denk 
Cc: Paul Mackerras 
Cc: Benjamin Herrenschmidt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'for-2.6.24' of master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx into merge

2007-11-20T00:39:26+00:00

[POWERPC] 4xx: Use virtual PVR value to init FPU on arch/ppc 440EP

2007-11-19T14:22:20+00:00

This fixes arch/ppc 440EP platforms to setup the FPU correctly.  A virtual
PVR is used, as 440GR platforms share an identical hardware PVR value and do
not have an FPU.

Signed-off-by: Josh Boyer

[POWERPC] Avoid unpaired stwcx. on some processors

2007-11-13T05:22:43+00:00

The context switch code in the kernel issues a dummy stwcx. to clear the
reservation, as recommended by the architecture.  However, some processors
can have issues if this stwcx to address A occurs while the reservation
is already held to a different address B.  To avoid this problem, the dummy
stwcx. needs to be paired with a dummy lwarx to the same address.

This adds the dummy lwarx, and creates a cpu feature bit to indicate
which cpus are affected.  Tested on mpc8641_hpcn_defconfig in
arch/powerpc; build tested in arch/ppc.

Signed-off-by: Becky Bruce 
Signed-off-by: Paul Mackerras

[POWERPC] 4xx: Deal with 44x virtually tagged icache

2007-11-01T12:15:30+00:00

The 44x family has an interesting "feature" which is a virtually
tagged instruction cache (yuck !). So far, we haven't dealt with
it properly, which means we've been mostly lucky or people didn't
report the problems, unless people have been running custom patches
in their distro...

This is an attempt at fixing it properly. I chose to do it by
setting a global flag whenever we change a PTE that was previously
marked executable, and flush the entire instruction cache upon
return to user space when that happens.

This is a bit heavy handed, but it's hard to do more fine grained
flushes as the icbi instruction, on those processor, for some very
strange reasons (since the cache is virtually mapped) still requires
a valid TLB entry for reading in the target address space, which
isn't something I want to deal with.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Josh Boyer

[POWERPC] 4xx: Fix 4xx flush_tlb_page()

2007-11-01T12:15:09+00:00

On 4xx CPUs, the current implementation of flush_tlb_page() uses
a low level _tlbie() assembly function that only works for the
current PID. Thus, invalidations caused by, for example, a COW
fault triggered by get_user_pages() from a different context will
not work properly, causing among other things, gdb breakpoints
to fail.

This patch adds a "pid" argument to _tlbie() on 4xx processors,
and uses it to flush entries in the right context. FSL BookE
also gets the argument but it seems they don't need it (their
tlbivax form ignores the PID when invalidating according to the
document I have).

Signed-off-by: Benjamin Herrenschmidt 
Acked-by: Kumar Gala 
Signed-off-by: Josh Boyer

pid namespaces: define is_global_init() and is_container_init()

2007-10-19T18:53:37+00:00

is_init() is an ambiguous name for the pid==1 check.  Split it into
is_global_init() and is_container_init().

A cgroup init has it's tsk->pid == 1.

A global init also has it's tsk->pid == 1 and it's active pid namespace
is the init_pid_ns.  But rather than check the active pid namespace,
compare the task structure with 'init_pid_ns.child_reaper', which is
initialized during boot to the /sbin/init process and never changes.

Changelog:

	2.6.22-rc4-mm2-pidns1:
	- Use 'init_pid_ns.child_reaper' to determine if a given task is the
	  global init (/sbin/init) process. This would improve performance
	  and remove dependence on the task_pid().

	2.6.21-mm2-pidns2:

	- [Sukadev Bhattiprolu] Changed is_container_init() calls in {powerpc,
	  ppc,avr32}/traps.c for the _exception() call to is_global_init().
	  This way, we kill only the cgroup if the cgroup's init has a
	  bug rather than force a kernel panic.

[akpm@linux-foundation.org: fix comment]
[sukadev@us.ibm.com: Use is_global_init() in arch/m32r/mm/fault.c]
[bunk@stusta.de: kernel/pid.c: remove unused exports]
[sukadev@us.ibm.com: Fix capability.c to work with threaded init]
Signed-off-by: Serge E. Hallyn 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Pavel Emelianov 
Cc: Eric W. Biederman 
Cc: Cedric Le Goater 
Cc: Dave Hansen 
Cc: Herbert Poetzel 
Cc: Kirill Korotaev 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PPC] Use cpu setup routines from cpu_setup_44x.S for ARCH=ppc

2007-10-04T01:02:09+00:00

Commit 8112753bb2c0045398c89d0647792b39805f6d40 made 44x in
ARCH=powerpc builds use cpu setup routines in cpu_setup_44x.S,
but didn't make a similar change for ARCH=ppc, and consequently
the ARCH=ppc builds fail with undefined symbols (since both use
the same cputable.c).

This fixes it by including cpu_setup_44x.S in the ARCH=ppc builds,
and by taking out the now-redundant FPU initialization in
arch/ppc/kernel/head_44x.S.

Signed-off-by: Paul Mackerras

[POWERPC] Fix ppc kernels after build-id addition

2007-09-22T04:49:21+00:00

This patch fixes arch/ppc kernels, at least for prep subarch, after
build-id addition.  Without this, kernels were 3 times the size and
bootloader refused to load them.  Now they are back to normal again.

Tested only with Roland McGrath's "Use LDFLAGS_MODULE only for .ko
links" patch applied - boots and works fine.

Signed-off-by: Meelis Roos 
Signed-off-by: Paul Mackerras

[POWERPC] Remove APUS support from arch/ppc

2007-09-17T05:15:04+00:00

Current status of APUS:
- arch/powerpc/: removed in 2.6.23
- arch/ppc/: marked BROKEN since 2 years

This therefore removes the remaining parts of APUS support from
arch/ppc, include/asm-ppc, arch/powerpc and include/asm-powerpc.

Signed-off-by: Adrian Bunk 
Signed-off-by: Paul Mackerras