linux/include/asm-powerpc, branch v2.6.26

Correct hash flushing from huge_ptep_set_wrprotect()

2008-07-08T16:27:58Z

As Andy Whitcroft recently pointed out, the current powerpc version of huge_ptep_set_wrprotect() has a bug. It just calls ptep_set_wrprotect() which in turn calls pte_update() then hpte_need_flush() with the 'huge' argument set to 0. This will cause hpte_need_flush() to flush the wrong hash entries (of any). Andy's fix for this is already in the powerpc tree as commit 016b33c4958681c24056abed8ec95844a0da80a3. I have confirmed this is a real bug, not masked by some other synchronization, with a new testcase for libhugetlbfs. A process write a (MAP_PRIVATE) hugepage mapping, fork(), then alter the mapping and have the child incorrectly see the second write. Therefore, this should be fixed for 2.6.26, and for the stable tree. Here is a suitable patch for 2.6.26, which I think will also be suitable for the stable tree (neither of the headers in question has been changed much recently). It is cut down slighlty from Andy's original version, in that it does not include a 32-bit version of huge_ptep_set_wrprotect(). Currently, hugepages are not supported on any 32-bit powerpc platform. When they are, a suitable 32-bit version can be added - the only 32-bit hardware which supports hugepages does not use the conventional hashtable MMU and so will have different needs anyway. Signed-off-by: Andy Whitcroft Signed-off-by: David Gibson Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Linus Torvalds

kbuild: fix a.out.h export to userspace with O= build.

2008-06-27T21:13:54Z

We need to check for existence of the a.out.h header in the source tree, not the object tree, if we want it to get the right answer with O=. Signed-off-by: David Woodhouse Signed-off-by: Sam Ravnborg

[POWERPC] Build fix for drivers/macintosh/mediabay.c

2008-06-16T05:00:47Z

This fixes the following build error with CONFIG_BLK_DEV_IDE_PMAC=n: <-- snip --> ... CC drivers/macintosh/mediabay.o /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/macintosh/mediabay.c: In function 'check_media_bay': /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/macintosh/mediabay.c:428: error: 'struct media_bay_info' has no member named 'cd_index' make[3]: *** [drivers/macintosh/mediabay.o] Error 1 <-- snip --> Reported-by: Adrian Bunk Signed-off-by: Adrian Bunk Signed-off-by: Paul Mackerras

[POWERPC] Fix rmb to order cacheable vs. noncacheable

2008-06-16T05:00:20Z

lwsync is explicitly defined not to have any effect on the ordering of accesses to device memory, so it cannot be used for rmb(). sync appears to be the only barrier which fits the bill. Signed-off-by: Nick Piggin Acked-by: Benjamin Herrenschmidt Signed-off-by: Paul Mackerras

Merge branch 'linux-2.6' into merge

2008-06-16T04:53:25Z

powerpc/spufs: remove class_0_dsisr from spu exception handling

2008-06-16T04:35:00Z

According to the CBEA, the SPU dsisr is not updated for class 0 exceptions. spu_stopped() is testing the dsisr that was passed to it from the class 0 exception handler, so we return a false positive here. This patch cleans up the interrupt handler and erroneous tests in spu_stopped. It also removes the fields from the csa since it is not needed to process class 0 events. Signed-off-by: Luke Browning Signed-off-by: Jeremy Kerr

KVM: ppc: Remove duplicate function

2008-06-06T18:22:09Z

This was left behind from some code movement. Signed-off-by: Hollis Blanchard Signed-off-by: Avi Kivity

[POWERPC] Add "memory" clobber to MMIO accessors

2008-05-31T07:08:28Z

Gcc might re-order MMIO accessors vs. surrounding consistent memory accesses, which is a "bad thing", and could break drivers. This fixes it by adding a "memory" clobber to the MMIO accessors, which should prevent gcc from doing that reordering. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Paul Mackerras

[POWERPC] mpic: Fix use of uninitialized variable

2008-05-23T06:15:37Z

Compiling ppc64_defconfig with gcc 4.3 gives thes warnings: arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_get_priority': arch/powerpc/sysdev/mpic.c:1351: warning: 'is_ipi' may be used uninitialized in this function arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_set_priority': arch/powerpc/sysdev/mpic.c:1328: warning: 'is_ipi' may be used uninitialized in this function It turns out that in the cases where is_ipi is uninitialized, another variable (mpic) will be NULL and it is dereferenced. Protect against this by returning if mpic is NULL in mpic_irq_set_priority, and removing mpic_irq_get_priority completely as it has no in tree callers. This has the nice side effect of making the warning go away. Signed-off-by: Stephen Rothwell Acked-by: Benjamin Herrenschmidt Signed-off-by: Paul Mackerras

[POWERPC] Fix uninitialized variable bug in copy_{to|from}_user

2008-05-15T10:49:52Z

Calls to copy_to_user() or copy_from_user() can fail when copying N bytes, where N is a constant less than 8, but not 1, 2, 4, or 8, because 'ret' is not initialized and is only set if the size is 1, 2, 4 or 8, but is tested after the switch statement for any constant size <= 8. This fixes it by initializing 'ret' to 1, causing the code to fall through to the __copy_tofrom_user call for sizes other than 1, 2, 4 or 8. Signed-off-by: Dave Scidmore Signed-off-by: Nate Case Signed-off-by: Paul Mackerras