* [PATCH 2/2] Make sure we copy all cpu_spec features except PMC related ones
From: Michael Ellerman @ 2009-02-23 2:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, shaggy
In-Reply-To: <689159d7e17a2227e6000b51911750503eed1778.1235355941.git.michael@ellerman.id.au>
When identify_cpu() is called a second time with a logical PVR, it
only copies a subset of the cpu_spec fields so as to avoid overwriting
the performance monitor fields that were initialized based on the
real PVR.
However some of the other, non performance monitor related fields are
also not copied:
* pvr_mask
* pvr_value
* mmu_features
* machine_check
The fact that pvr_mask is not copied can result in show_cpuinfo()
showing the cpu as "unknown", if we override an unknown PVR with a
logical one - as reported by Shaggy.
So change the logic to copy all fields, and then put back the PMC
related ones in the case that we're overwriting a real PVR with a
logical one.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/cputable.c | 28 ++++++++++++++++------------
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 944bd01..77febd3 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1765,22 +1765,27 @@ static struct cpu_spec the_cpu_spec;
static void __init setup_cpu_spec(unsigned long offset, struct cpu_spec *s)
{
struct cpu_spec *t = &the_cpu_spec;
+ struct cpu_spec old;
+
t = PTRRELOC(t);
+ old = *t;
+
+ /* Copy everything, then do fixups */
+ *t = *s;
/*
* If we are overriding a previous value derived from the real
* PVR with a new value obtained using a logical PVR value,
* don't modify the performance monitor fields.
*/
- if (t->num_pmcs && !s->num_pmcs) {
- t->cpu_name = s->cpu_name;
- t->cpu_features = s->cpu_features;
- t->cpu_user_features = s->cpu_user_features;
- t->icache_bsize = s->icache_bsize;
- t->dcache_bsize = s->dcache_bsize;
- t->cpu_setup = s->cpu_setup;
- t->cpu_restore = s->cpu_restore;
- t->platform = s->platform;
+ if (old.num_pmcs && !s->num_pmcs) {
+ t->num_pmcs = old.num_pmcs;
+ t->pmc_type = old.pmc_type;
+ t->oprofile_type = old.oprofile_type;
+ t->oprofile_mmcra_sihv = old.oprofile_mmcra_sihv;
+ t->oprofile_mmcra_sipr = old.oprofile_mmcra_sipr;
+ t->oprofile_mmcra_clear = old.oprofile_mmcra_clear;
+
/*
* If we have passed through this logic once before and
* have pulled the default case because the real PVR was
@@ -1794,10 +1799,9 @@ static void __init setup_cpu_spec(unsigned long offset, struct cpu_spec *s)
* and, in that case, keep the current value for
* oprofile_cpu_type.
*/
- if (t->oprofile_cpu_type == NULL)
+ if (old.oprofile_cpu_type == NULL)
t->oprofile_cpu_type = s->oprofile_cpu_type;
- } else
- *t = *s;
+ }
*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
--
1.5.5
^ permalink raw reply related
* [PATCH 1/2] Deindentify identify_cpu()
From: Michael Ellerman @ 2009-02-23 2:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, shaggy
The for-loop body of identify_cpu() has gotten a little big, so move the
loop body logic into a separate function. No other changes.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/cputable.c | 122 +++++++++++++++++++++-------------------
1 files changed, 64 insertions(+), 58 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 923f87a..944bd01 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1762,74 +1762,80 @@ static struct cpu_spec __initdata cpu_specs[] = {
static struct cpu_spec the_cpu_spec;
-struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)
+static void __init setup_cpu_spec(unsigned long offset, struct cpu_spec *s)
{
- struct cpu_spec *s = cpu_specs;
struct cpu_spec *t = &the_cpu_spec;
- int i;
-
- s = PTRRELOC(s);
t = PTRRELOC(t);
- for (i = 0; i < ARRAY_SIZE(cpu_specs); i++,s++)
- if ((pvr & s->pvr_mask) == s->pvr_value) {
- /*
- * If we are overriding a previous value derived
- * from the real PVR with a new value obtained
- * using a logical PVR value, don't modify the
- * performance monitor fields.
- */
- if (t->num_pmcs && !s->num_pmcs) {
- t->cpu_name = s->cpu_name;
- t->cpu_features = s->cpu_features;
- t->cpu_user_features = s->cpu_user_features;
- t->icache_bsize = s->icache_bsize;
- t->dcache_bsize = s->dcache_bsize;
- t->cpu_setup = s->cpu_setup;
- t->cpu_restore = s->cpu_restore;
- t->platform = s->platform;
- /*
- * If we have passed through this logic once
- * before and have pulled the default case
- * because the real PVR was not found inside
- * cpu_specs[], then we are possibly running in
- * compatibility mode. In that case, let the
- * oprofiler know which set of compatibility
- * counters to pull from by making sure the
- * oprofile_cpu_type string is set to that of
- * compatibility mode. If the oprofile_cpu_type
- * already has a value, then we are possibly
- * overriding a real PVR with a logical one, and,
- * in that case, keep the current value for
- * oprofile_cpu_type.
- */
- if (t->oprofile_cpu_type == NULL)
- t->oprofile_cpu_type = s->oprofile_cpu_type;
- } else
- *t = *s;
- *PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
+ /*
+ * If we are overriding a previous value derived from the real
+ * PVR with a new value obtained using a logical PVR value,
+ * don't modify the performance monitor fields.
+ */
+ if (t->num_pmcs && !s->num_pmcs) {
+ t->cpu_name = s->cpu_name;
+ t->cpu_features = s->cpu_features;
+ t->cpu_user_features = s->cpu_user_features;
+ t->icache_bsize = s->icache_bsize;
+ t->dcache_bsize = s->dcache_bsize;
+ t->cpu_setup = s->cpu_setup;
+ t->cpu_restore = s->cpu_restore;
+ t->platform = s->platform;
+ /*
+ * If we have passed through this logic once before and
+ * have pulled the default case because the real PVR was
+ * not found inside cpu_specs[], then we are possibly
+ * running in compatibility mode. In that case, let the
+ * oprofiler know which set of compatibility counters to
+ * pull from by making sure the oprofile_cpu_type string
+ * is set to that of compatibility mode. If the
+ * oprofile_cpu_type already has a value, then we are
+ * possibly overriding a real PVR with a logical one,
+ * and, in that case, keep the current value for
+ * oprofile_cpu_type.
+ */
+ if (t->oprofile_cpu_type == NULL)
+ t->oprofile_cpu_type = s->oprofile_cpu_type;
+ } else
+ *t = *s;
+
+ *PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
- /*
- * Set the base platform string once; assumes
- * we're called with real pvr first.
- */
- if (*PTRRELOC(&powerpc_base_platform) == NULL)
- *PTRRELOC(&powerpc_base_platform) = t->platform;
+ /*
+ * Set the base platform string once; assumes
+ * we're called with real pvr first.
+ */
+ if (*PTRRELOC(&powerpc_base_platform) == NULL)
+ *PTRRELOC(&powerpc_base_platform) = t->platform;
#if defined(CONFIG_PPC64) || defined(CONFIG_BOOKE)
- /* ppc64 and booke expect identify_cpu to also call
- * setup_cpu for that processor. I will consolidate
- * that at a later time, for now, just use #ifdef.
- * we also don't need to PTRRELOC the function pointer
- * on ppc64 and booke as we are running at 0 in real
- * mode on ppc64 and reloc_offset is always 0 on booke.
- */
- if (s->cpu_setup) {
- s->cpu_setup(offset, s);
- }
+ /* ppc64 and booke expect identify_cpu to also call setup_cpu for
+ * that processor. I will consolidate that at a later time, for now,
+ * just use #ifdef. We also don't need to PTRRELOC the function
+ * pointer on ppc64 and booke as we are running at 0 in real mode
+ * on ppc64 and reloc_offset is always 0 on booke.
+ */
+ if (s->cpu_setup) {
+ s->cpu_setup(offset, s);
+ }
#endif /* CONFIG_PPC64 || CONFIG_BOOKE */
+}
+
+struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)
+{
+ struct cpu_spec *s = cpu_specs;
+ int i;
+
+ s = PTRRELOC(s);
+
+ for (i = 0; i < ARRAY_SIZE(cpu_specs); i++,s++) {
+ if ((pvr & s->pvr_mask) == s->pvr_value) {
+ setup_cpu_spec(offset, s);
return s;
}
+ }
+
BUG();
+
return NULL;
}
--
1.5.5
^ permalink raw reply related
* [PATCH] powerpc: Wire up /proc/vmallocinfo to our ioremap()
From: Benjamin Herrenschmidt @ 2009-02-23 2:19 UTC (permalink / raw)
To: linuxppc-dev
This adds the necessary bits and pieces to powerpc implementation of
ioremap to benefit from caller tracking in /proc/vmallocinfo, at least
for ioremap's done after mem init as the older ones aren't tracked.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/io.h | 6 ++++++
arch/powerpc/include/asm/machdep.h | 2 +-
arch/powerpc/mm/pgtable_32.c | 14 +++++++++++---
arch/powerpc/mm/pgtable_64.c | 25 +++++++++++++++++--------
arch/powerpc/platforms/cell/io-workarounds.c | 4 ++--
arch/powerpc/platforms/iseries/setup.c | 2 +-
6 files changed, 38 insertions(+), 15 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/io.h 2009-02-04 15:37:43.000000000 +1100
+++ linux-work/arch/powerpc/include/asm/io.h 2009-02-04 15:38:30.000000000 +1100
@@ -632,6 +632,9 @@ static inline void iosync(void)
* ioremap_flags and cannot be hooked (but can be used by a hook on one
* of the previous ones)
*
+ * * __ioremap_caller is the same as above but takes an explicit caller
+ * reference rather than using __builtin_return_address(0)
+ *
* * __iounmap, is the low level implementation used by iounmap and cannot
* be hooked (but can be used by a hook on iounmap)
*
@@ -646,6 +649,9 @@ extern void iounmap(volatile void __iome
extern void __iomem *__ioremap(phys_addr_t, unsigned long size,
unsigned long flags);
+extern void __iomem *__ioremap_caller(phys_addr_t, unsigned long size,
+ unsigned long flags, void *caller);
+
extern void __iounmap(volatile void __iomem *addr);
extern void __iomem * __ioremap_at(phys_addr_t pa, void *ea,
Index: linux-work/arch/powerpc/include/asm/machdep.h
===================================================================
--- linux-work.orig/arch/powerpc/include/asm/machdep.h 2009-02-04 15:35:20.000000000 +1100
+++ linux-work/arch/powerpc/include/asm/machdep.h 2009-02-04 15:35:25.000000000 +1100
@@ -90,7 +90,7 @@ struct machdep_calls {
void (*tce_flush)(struct iommu_table *tbl);
void __iomem * (*ioremap)(phys_addr_t addr, unsigned long size,
- unsigned long flags);
+ unsigned long flags, void *caller);
void (*iounmap)(volatile void __iomem *token);
#ifdef CONFIG_PM
Index: linux-work/arch/powerpc/mm/pgtable_32.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/pgtable_32.c 2009-02-04 15:40:22.000000000 +1100
+++ linux-work/arch/powerpc/mm/pgtable_32.c 2009-02-04 15:41:43.000000000 +1100
@@ -129,7 +129,8 @@ pgtable_t pte_alloc_one(struct mm_struct
void __iomem *
ioremap(phys_addr_t addr, unsigned long size)
{
- return __ioremap(addr, size, _PAGE_NO_CACHE | _PAGE_GUARDED);
+ return __ioremap_caller(addr, size, _PAGE_NO_CACHE | _PAGE_GUARDED,
+ __builtin_return_address(0));
}
EXPORT_SYMBOL(ioremap);
@@ -143,13 +144,20 @@ ioremap_flags(phys_addr_t addr, unsigned
/* we don't want to let _PAGE_USER and _PAGE_EXEC leak out */
flags &= ~(_PAGE_USER | _PAGE_EXEC | _PAGE_HWEXEC);
- return __ioremap(addr, size, flags);
+ return __ioremap_caller(addr, size, flags, __builtin_return_address(0));
}
EXPORT_SYMBOL(ioremap_flags);
void __iomem *
__ioremap(phys_addr_t addr, unsigned long size, unsigned long flags)
{
+ return __ioremap_caller(addr, size, flags, __builtin_return_address(0));
+}
+
+void __iomem *
+__ioremap_caller(phys_addr_t addr, unsigned long size, unsigned long flags,
+ void *caller)
+{
unsigned long v, i;
phys_addr_t p;
int err;
@@ -212,7 +220,7 @@ __ioremap(phys_addr_t addr, unsigned lon
if (mem_init_done) {
struct vm_struct *area;
- area = get_vm_area(size, VM_IOREMAP);
+ area = get_vm_area_caller(size, VM_IOREMAP, caller);
if (area == 0)
return NULL;
v = (unsigned long) area->addr;
Index: linux-work/arch/powerpc/mm/pgtable_64.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/pgtable_64.c 2009-02-04 15:31:20.000000000 +1100
+++ linux-work/arch/powerpc/mm/pgtable_64.c 2009-02-04 15:50:54.000000000 +1100
@@ -144,8 +144,8 @@ void __iounmap_at(void *ea, unsigned lon
unmap_kernel_range((unsigned long)ea, size);
}
-void __iomem * __ioremap(phys_addr_t addr, unsigned long size,
- unsigned long flags)
+void __iomem * __ioremap_caller(phys_addr_t addr, unsigned long size,
+ unsigned long flags, void *caller)
{
phys_addr_t paligned;
void __iomem *ret;
@@ -168,8 +168,9 @@ void __iomem * __ioremap(phys_addr_t add
if (mem_init_done) {
struct vm_struct *area;
- area = __get_vm_area(size, VM_IOREMAP,
- ioremap_bot, IOREMAP_END);
+ area = __get_vm_area_caller(size, VM_IOREMAP,
+ ioremap_bot, IOREMAP_END,
+ caller);
if (area == NULL)
return NULL;
ret = __ioremap_at(paligned, area->addr, size, flags);
@@ -186,19 +187,27 @@ void __iomem * __ioremap(phys_addr_t add
return ret;
}
+void __iomem * __ioremap(phys_addr_t addr, unsigned long size,
+ unsigned long flags)
+{
+ return __ioremap_caller(addr, size, flags, __builtin_return_address(0));
+}
void __iomem * ioremap(phys_addr_t addr, unsigned long size)
{
unsigned long flags = _PAGE_NO_CACHE | _PAGE_GUARDED;
+ void *caller = __builtin_return_address(0);
if (ppc_md.ioremap)
- return ppc_md.ioremap(addr, size, flags);
- return __ioremap(addr, size, flags);
+ return ppc_md.ioremap(addr, size, flags, caller);
+ return __ioremap_caller(addr, size, flags, caller);
}
void __iomem * ioremap_flags(phys_addr_t addr, unsigned long size,
unsigned long flags)
{
+ void *caller = __builtin_return_address(0);
+
/* writeable implies dirty for kernel addresses */
if (flags & _PAGE_RW)
flags |= _PAGE_DIRTY;
@@ -207,8 +216,8 @@ void __iomem * ioremap_flags(phys_addr_t
flags &= ~(_PAGE_USER | _PAGE_EXEC);
if (ppc_md.ioremap)
- return ppc_md.ioremap(addr, size, flags);
- return __ioremap(addr, size, flags);
+ return ppc_md.ioremap(addr, size, flags, caller);
+ return __ioremap_caller(addr, size, flags, caller);
}
Index: linux-work/arch/powerpc/platforms/cell/io-workarounds.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/cell/io-workarounds.c 2009-02-04 15:36:48.000000000 +1100
+++ linux-work/arch/powerpc/platforms/cell/io-workarounds.c 2009-02-04 15:51:27.000000000 +1100
@@ -131,10 +131,10 @@ static const struct ppc_pci_io __devinit
};
static void __iomem *iowa_ioremap(phys_addr_t addr, unsigned long size,
- unsigned long flags)
+ unsigned long flags, void *caller)
{
struct iowa_bus *bus;
- void __iomem *res = __ioremap(addr, size, flags);
+ void __iomem *res = __ioremap_caller(addr, size, flags, caller);
int busno;
bus = iowa_pci_find(0, (unsigned long)addr);
Index: linux-work/arch/powerpc/platforms/iseries/setup.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/iseries/setup.c 2009-02-04 15:39:22.000000000 +1100
+++ linux-work/arch/powerpc/platforms/iseries/setup.c 2009-02-04 15:39:28.000000000 +1100
@@ -617,7 +617,7 @@ static void iseries_dedicated_idle(void)
}
static void __iomem *iseries_ioremap(phys_addr_t address, unsigned long size,
- unsigned long flags)
+ unsigned long flags, void *caller)
{
return (void __iomem *)address;
}
^ permalink raw reply
* Can not get "new" MPC8313e-RDB to boot "as-shipped" flash image
From: Eric Cottrell @ 2009-02-22 23:23 UTC (permalink / raw)
To: linuxppc-dev
Hello,
This is getting frustrating and I am beginning to think someone messed this=
board up and returned it. I would think it would boot up the default flas=
h image out of the box with very little trouble.
Board is a MPC8313e-RDB Rev A4. I set the dip switches per the instruction=
s, S4 all off and S3 all on.
Uboot comes up but I can not boot either the default images in the flash or=
images I built with ltib and tftped. I did not touch the flash. I get WA=
RNING: could not set linux,stdout-path FDT_ERR_NOTFOUND and ERROR: /chosen =
node create failed - must RESET the board to recover. The board resets.
A friend has the same board but his U-Boot is Version 1.3.0 (Jun 19 2008 - =
13:41:53) MPC83XX and some environment variables are different. I do not h=
ave the BOOTCMD variable but entered it manually.
I tried searching for on a solution but it is confusing because if aliases =
are needed why does the default dtb in the flash omit them?
This is what happens:
U-Boot 1.3.3 (Dec 8 2008 - 09:51:15) MPC83XX
Reset Status:
CPU: e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.666 MHz
Board: Freescale MPC8313ERDB
I2C: ready
DRAM: 128 MB
FLASH: 8 MB
In: serial
Out: serial
Err: serial
Net: TSEC0, TSEC1 [PRIME]
=3D> bootm fe100000 fe300000 fe700000
## Booting kernel from Legacy Image at fe100000 ...
Image Name: Linux-2.6.20
Created: 2007-08-24 14:59:01 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1722821 Bytes =3D 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Flattened Device Tree blob at fe700000
Booting using the fdt blob at 0xfe700000
## Loading init Ramdisk from Legacy Image at fe300000 ...
Image Name: uboot ext2 ramdisk rootfs
Created: 2007-08-24 15:01:41 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 2831355 Bytes =3D 2.7 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Device Tree to 007fd000, end 007fffff ... OK
WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND.
ERROR: /chosen node create failed - must RESET the board to recover.
Resetting the board.
U-Boot 1.3.3 (Dec 8 2008 - 09:51:15) MPC83XX
Reset Status: Software Hard, External/Internal Soft, External/Internal Hard
CPU: e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.666 MHz
Board: Freescale MPC8313ERDB
I2C: ready
DRAM: 128 MB
FLASH: 8 MB
In: serial
Out: serial
Err: serial
Net: TSEC0, TSEC1 [PRIME]
=3D>=20
73 Eric
^ permalink raw reply
* Re: Lock-up on PPC64
From: Benjamin Herrenschmidt @ 2009-02-22 22:42 UTC (permalink / raw)
To: malc; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0902221126220.3111@linmac.oyster.ru>
On Sun, 2009-02-22 at 11:35 +0300, malc wrote:
> After writing valgrind tool that was simulating Cell XER.SO syscall
> (mis)behaviour (pre ab598b6680f1e74c267d1547ee352f3e1e530f89 that is)
> and banging my had against the wall for a while trying to figure out
> which of the failing syscalls was responsible, i've tried to be simple
> and after only ~30 minutes came up with this, rather short, piece of
> code that knocks pre XER.SO patched kernels out cold:
>
> gcc -o xer -x assembler /dev/stdin -nostdlib <<eof
> .globl _start
> _start:
> addis 0,0,0x8000
> mtxer 0
> addi 0,0,1
> sc
Allright, but the XER patch fixes it... interesting. Oh well, I'll try
to figure out at some stage where we get something wrong in those old
kernels.
Cheers,
Ben.
^ permalink raw reply
* Re: CPU hotplug /sys entries are missing on 2.6.28 [PATCH]
From: Giuliano Pochini @ 2009-02-22 12:17 UTC (permalink / raw)
To: LinuxPPC-dev
In-Reply-To: <20090218221821.ca5d29eb.pochini@shiny.it>
On Wed, 18 Feb 2009 22:18:21 +0100
Giuliano Pochini <pochini@shiny.it> wrote:
> /sys/devices/system/cpu/cpu*/online don't exist anymore.
I think I found the bug. Is this patch ok ?
Signed-off-by: Giuliano Pochini <pochini@shiny.it>
--- linux-2.6.29-rc5/arch/powerpc/platforms/powermac/setup.c__orig 2009-02-14 00:31:30.000000000 +0100
+++ linux-2.6.29-rc5/arch/powerpc/platforms/powermac/setup.c 2009-02-21 22:44:14.000000000 +0100
@@ -746,4 +746,7 @@ define_machine(powermac) {
#if defined(CONFIG_HOTPLUG_CPU) && defined(CONFIG_PPC64)
.cpu_die = pmac_cpu_die,
#endif
+#if defined(CONFIG_HOTPLUG_CPU) && defined(CONFIG_PPC32)
+ .cpu_die = generic_mach_cpu_die,
+#endif
};
--
Giuliano.
^ permalink raw reply
* [patch 10/10] powerpc: Randomise PIEs
From: Anton Blanchard @ 2009-02-22 11:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090222114957.213647384@samba.org>
Randomise ELF_ET_DYN_BASE, which is used when loading position independent
executables.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/include/asm/elf.h
===================================================================
--- linux-2.6.orig/arch/powerpc/include/asm/elf.h 2009-02-22 21:18:04.000000000 +1100
+++ linux-2.6/arch/powerpc/include/asm/elf.h 2009-02-22 21:34:49.000000000 +1100
@@ -178,7 +178,8 @@
the loader. We need to make sure that it is out of the way of the program
that it will "exec", and that there is sufficient room for the brk. */
-#define ELF_ET_DYN_BASE (0x20000000)
+extern unsigned long randomize_et_dyn(unsigned long base);
+#define ELF_ET_DYN_BASE (randomize_et_dyn(0x20000000))
/*
* Our registers are always unsigned longs, whether we're a 32 bit
Index: linux-2.6/arch/powerpc/kernel/process.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/process.c 2009-02-22 21:21:14.000000000 +1100
+++ linux-2.6/arch/powerpc/kernel/process.c 2009-02-22 21:36:02.000000000 +1100
@@ -1154,3 +1154,13 @@
return ret;
}
+
+unsigned long randomize_et_dyn(unsigned long base)
+{
+ unsigned long ret = PAGE_ALIGN(base + brk_rnd());
+
+ if (ret < base)
+ return base;
+
+ return ret;
+}
--
^ permalink raw reply
* [patch 09/10] powerpc: Increase stack gap on 64bit binaries
From: Anton Blanchard @ 2009-02-22 11:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090222114957.213647384@samba.org>
On 64bit there is a possibility our stack and mmap randomisation will put
the two close enough such that we can't expand our stack to match the ulimit
specified.
To avoid this, start the upper mmap address at 1GB + 128MB below the top of our
address space, so in the worst case we end up with the same ~128MB hole as in
32bit. This works because we randomise the stack over a 1GB range.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/mm/mmap.c
===================================================================
--- linux-2.6.orig/arch/powerpc/mm/mmap.c 2009-02-21 09:52:23.000000000 +1100
+++ linux-2.6/arch/powerpc/mm/mmap.c 2009-02-21 10:36:36.000000000 +1100
@@ -30,9 +30,16 @@
/*
* Top of mmap area (just below the process stack).
*
- * Leave an at least ~128 MB hole.
+ * Leave at least a ~128 MB hole on 32bit applications.
+ *
+ * On 64bit applications we randomise the stack by 1GB so we need to
+ * space our mmap start address by a further 1GB, otherwise there is a
+ * chance the mmap area will end up closer to the stack than our ulimit
+ * requires.
*/
-#define MIN_GAP (128*1024*1024)
+#define MIN_GAP32 (128*1024*1024)
+#define MIN_GAP64 ((128 + 1024)*1024*1024UL)
+#define MIN_GAP ((is_32bit_task()) ? MIN_GAP32 : MIN_GAP64)
#define MAX_GAP (TASK_SIZE/6*5)
static inline int mmap_is_legacy(void)
--
^ permalink raw reply
* [patch 08/10] powerpc: Ensure random space between stack and mmaps
From: Anton Blanchard @ 2009-02-22 11:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090222114957.213647384@samba.org>
get_random_int() returns the same value within a 1 jiffy interval. This means
that the mmap and stack regions will almost always end up the same distance
apart, making a relative offset based attack possible.
To fix this, shift the randomness we use for the mmap region by 1 bit.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/mm/mmap.c
===================================================================
--- linux-2.6.orig/arch/powerpc/mm/mmap.c 2009-02-22 11:58:54.000000000 +1100
+++ linux-2.6/arch/powerpc/mm/mmap.c 2009-02-22 12:05:01.000000000 +1100
@@ -46,6 +46,14 @@
return sysctl_legacy_va_layout;
}
+/*
+ * Since get_random_int() returns the same value within a 1 jiffy window,
+ * we will almost always get the same randomisation for the stack and mmap
+ * region. This will mean the relative distance between stack and mmap will
+ * be the same.
+ *
+ * To avoid this we can shift the randomness by 1 bit.
+ */
static unsigned long mmap_rnd(void)
{
unsigned long rnd = 0;
@@ -53,11 +61,11 @@
if (current->flags & PF_RANDOMIZE) {
/* 8MB for 32bit, 1GB for 64bit */
if (is_32bit_task())
- rnd = (long)(get_random_int() % (1<<(23-PAGE_SHIFT)));
+ rnd = (long)(get_random_int() % (1<<(22-PAGE_SHIFT)));
else
- rnd = (long)(get_random_int() % (1<<(30-PAGE_SHIFT)));
+ rnd = (long)(get_random_int() % (1<<(29-PAGE_SHIFT)));
}
- return rnd << PAGE_SHIFT;
+ return (rnd << PAGE_SHIFT) * 2;
}
static inline unsigned long mmap_base(void)
--
^ permalink raw reply
* [patch 07/10] powerpc: Randomise the brk region
From: Anton Blanchard @ 2009-02-22 11:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090222114957.213647384@samba.org>
Randomize the heap.
before:
tundro2:~ # sleep 1 & cat /proc/${!}/maps | grep heap
10017000-10118000 rw-p 10017000 00:00 0 [heap]
10017000-10118000 rw-p 10017000 00:00 0 [heap]
10017000-10118000 rw-p 10017000 00:00 0 [heap]
10017000-10118000 rw-p 10017000 00:00 0 [heap]
10017000-10118000 rw-p 10017000 00:00 0 [heap]
after
tundro2:~ # sleep 1 & cat /proc/${!}/maps | grep heap
19419000-1951a000 rw-p 19419000 00:00 0 [heap]
325ff000-32700000 rw-p 325ff000 00:00 0 [heap]
1a97c000-1aa7d000 rw-p 1a97c000 00:00 0 [heap]
1cc60000-1cd61000 rw-p 1cc60000 00:00 0 [heap]
1afa9000-1b0aa000 rw-p 1afa9000 00:00 0 [heap]
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/include/asm/elf.h
===================================================================
--- linux-2.6.orig/arch/powerpc/include/asm/elf.h 2009-02-20 16:06:32.000000000 +1100
+++ linux-2.6/arch/powerpc/include/asm/elf.h 2009-02-22 11:58:02.000000000 +1100
@@ -275,6 +275,9 @@
(0x7ff >> (PAGE_SHIFT - 12)) : \
(0x3ffff >> (PAGE_SHIFT - 12)))
+extern unsigned long arch_randomize_brk(struct mm_struct *mm);
+#define arch_randomize_brk arch_randomize_brk
+
#endif /* __KERNEL__ */
/*
Index: linux-2.6/arch/powerpc/kernel/process.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/process.c 2009-02-20 16:06:32.000000000 +1100
+++ linux-2.6/arch/powerpc/kernel/process.c 2009-02-22 11:58:02.000000000 +1100
@@ -1131,3 +1131,26 @@
sp -= get_random_int() & ~PAGE_MASK;
return sp & ~0xf;
}
+
+static inline unsigned long brk_rnd(void)
+{
+ unsigned long rnd = 0;
+
+ /* 8MB for 32bit, 1GB for 64bit */
+ if (is_32bit_task())
+ rnd = (long)(get_random_int() % (1<<(23-PAGE_SHIFT)));
+ else
+ rnd = (long)(get_random_int() % (1<<(30-PAGE_SHIFT)));
+
+ return rnd << PAGE_SHIFT;
+}
+
+unsigned long arch_randomize_brk(struct mm_struct *mm)
+{
+ unsigned long ret = PAGE_ALIGN(mm->brk + brk_rnd());
+
+ if (ret < mm->brk)
+ return mm->brk;
+
+ return ret;
+}
--
^ permalink raw reply
* [patch 06/10] powerpc: Randomise lower bits of stack address
From: Anton Blanchard @ 2009-02-22 11:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090222114957.213647384@samba.org>
Randomise the lower bits of the stack address. More randomisation is good for
security but the scatter can also help with SMT threads that share an L1. A
quick test case shows this working:
int main()
{
int sp;
printf("%x\n", (unsigned long)&sp & 4095);
}
before:
80
80
80
80
80
after:
610
490
300
6b0
d80
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/include/asm/system.h
===================================================================
--- linux-2.6.orig/arch/powerpc/include/asm/system.h 2009-02-20 13:39:05.000000000 +1100
+++ linux-2.6/arch/powerpc/include/asm/system.h 2009-02-20 13:51:39.000000000 +1100
@@ -531,7 +531,7 @@
#define cmpxchg64_local(ptr, o, n) __cmpxchg64_local_generic((ptr), (o), (n))
#endif
-#define arch_align_stack(x) (x)
+extern unsigned long arch_align_stack(unsigned long sp);
/* Used in very early kernel initialization. */
extern unsigned long reloc_offset(void);
Index: linux-2.6/arch/powerpc/kernel/process.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/process.c 2009-02-20 13:39:05.000000000 +1100
+++ linux-2.6/arch/powerpc/kernel/process.c 2009-02-20 13:51:39.000000000 +1100
@@ -34,6 +34,8 @@
#include <linux/hardirq.h>
#include <linux/utsname.h>
#include <linux/kernel_stat.h>
+#include <linux/personality.h>
+#include <linux/random.h>
#include <asm/pgtable.h>
#include <asm/uaccess.h>
@@ -1122,3 +1124,10 @@
}
#endif /* THREAD_SHIFT < PAGE_SHIFT */
+
+unsigned long arch_align_stack(unsigned long sp)
+{
+ if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
+ sp -= get_random_int() & ~PAGE_MASK;
+ return sp & ~0xf;
+}
--
^ permalink raw reply
* [patch 05/10] powerpc: More stack randomisation for 64bit binaries
From: Anton Blanchard @ 2009-02-22 11:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090222114957.213647384@samba.org>
At the moment we randomise the stack by 8MB on 32bit and 64bit tasks. Since we
have a lot more address space to play with on 64bit, lets do what x86 does and
increase that randomisation to 1GB:
before:
# for i in seq `1 10` ; do sleep 1 & cat /proc/${!}/maps | grep stack; done
fffffebc000-fffffed1000 rw-p ffffffeb000 00:00 0 [stack]
ffffff5a000-ffffff6f000 rw-p ffffffeb000 00:00 0 [stack]
fffffdb2000-fffffdc7000 rw-p ffffffeb000 00:00 0 [stack]
fffffd3e000-fffffd53000 rw-p ffffffeb000 00:00 0 [stack]
fffffad9000-fffffaee000 rw-p ffffffeb000 00:00 0 [stack]
after:
# for i in seq `1 10` ; do sleep 1 & cat /proc/${!}/maps | grep stack; done
ffff5c27000-ffff5c3c000 rw-p ffffffeb000 00:00 0 [stack]
fffebe5e000-fffebe73000 rw-p ffffffeb000 00:00 0 [stack]
fffcb298000-fffcb2ad000 rw-p ffffffeb000 00:00 0 [stack]
fffc719d000-fffc71b2000 rw-p ffffffeb000 00:00 0 [stack]
fffe01af000-fffe01c4000 rw-p ffffffeb000 00:00 0 [stack]
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/include/asm/elf.h
===================================================================
--- linux-2.6.orig/arch/powerpc/include/asm/elf.h 2009-02-20 13:39:05.000000000 +1100
+++ linux-2.6/arch/powerpc/include/asm/elf.h 2009-02-20 13:51:20.000000000 +1100
@@ -270,6 +270,11 @@
int uses_interp);
#define VDSO_AUX_ENT(a,b) NEW_AUX_ENT(a,b);
+/* 1GB for 64bit, 8MB for 32bit */
+#define STACK_RND_MASK (is_32bit_task() ? \
+ (0x7ff >> (PAGE_SHIFT - 12)) : \
+ (0x3ffff >> (PAGE_SHIFT - 12)))
+
#endif /* __KERNEL__ */
/*
--
^ permalink raw reply
* [patch 04/10] powerpc: Randomise mmap start address
From: Anton Blanchard @ 2009-02-22 11:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090222114957.213647384@samba.org>
Randomise mmap start address - 8MB on 32bit and 1GB on 64bit tasks.
Until ppc32 uses the mmap.c functionality, this is ppc64 specific.
Before:
# ./test & cat /proc/${!}/maps|tail -2|head -1
f75fe000-f7fff000 rw-p f75fe000 00:00 0
f75fe000-f7fff000 rw-p f75fe000 00:00 0
f75fe000-f7fff000 rw-p f75fe000 00:00 0
f75fe000-f7fff000 rw-p f75fe000 00:00 0
f75fe000-f7fff000 rw-p f75fe000 00:00 0
After:
# ./test & cat /proc/${!}/maps|tail -2|head -1
f718b000-f7b8c000 rw-p f718b000 00:00 0
f7551000-f7f52000 rw-p f7551000 00:00 0
f6ee7000-f78e8000 rw-p f6ee7000 00:00 0
f74d4000-f7ed5000 rw-p f74d4000 00:00 0
f6e9d000-f789e000 rw-p f6e9d000 00:00 0
Similar for 64bit, but with 1GB of scatter:
# ./test & cat /proc/${!}/maps|tail -2|head -1
fffb97b5000-fffb97b6000 rw-p fffb97b5000 00:00 0
fffce9a3000-fffce9a4000 rw-p fffce9a3000 00:00 0
fffeaaf2000-fffeaaf3000 rw-p fffeaaf2000 00:00 0
fffd88ac000-fffd88ad000 rw-p fffd88ac000 00:00 0
fffbc62e000-fffbc62f000 rw-p fffbc62e000 00:00 0
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/mm/mmap.c
===================================================================
--- linux-2.6.orig/arch/powerpc/mm/mmap.c 2009-02-20 13:46:35.000000000 +1100
+++ linux-2.6/arch/powerpc/mm/mmap.c 2009-02-20 13:47:23.000000000 +1100
@@ -24,6 +24,7 @@
#include <linux/personality.h>
#include <linux/mm.h>
+#include <linux/random.h>
#include <linux/sched.h>
/*
@@ -45,6 +46,20 @@
return sysctl_legacy_va_layout;
}
+static unsigned long mmap_rnd(void)
+{
+ unsigned long rnd = 0;
+
+ if (current->flags & PF_RANDOMIZE) {
+ /* 8MB for 32bit, 1GB for 64bit */
+ if (is_32bit_task())
+ rnd = (long)(get_random_int() % (1<<(23-PAGE_SHIFT)));
+ else
+ rnd = (long)(get_random_int() % (1<<(30-PAGE_SHIFT)));
+ }
+ return rnd << PAGE_SHIFT;
+}
+
static inline unsigned long mmap_base(void)
{
unsigned long gap = current->signal->rlim[RLIMIT_STACK].rlim_cur;
@@ -54,7 +69,7 @@
else if (gap > MAX_GAP)
gap = MAX_GAP;
- return TASK_SIZE - (gap & PAGE_MASK);
+ return PAGE_ALIGN(TASK_SIZE - gap - mmap_rnd());
}
/*
--
^ permalink raw reply
* [patch 03/10] powerpc: Rearrange mmap.c
From: Anton Blanchard @ 2009-02-22 11:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090222114957.213647384@samba.org>
Rearrange mmap.c to better match the x86 version.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/mm/mmap.c
===================================================================
--- linux-2.6.orig/arch/powerpc/mm/mmap.c 2009-02-20 13:40:26.000000000 +1100
+++ linux-2.6/arch/powerpc/mm/mmap.c 2009-02-20 13:41:06.000000000 +1100
@@ -34,6 +34,17 @@
#define MIN_GAP (128*1024*1024)
#define MAX_GAP (TASK_SIZE/6*5)
+static inline int mmap_is_legacy(void)
+{
+ if (current->personality & ADDR_COMPAT_LAYOUT)
+ return 1;
+
+ if (current->signal->rlim[RLIMIT_STACK].rlim_cur == RLIM_INFINITY)
+ return 1;
+
+ return sysctl_legacy_va_layout;
+}
+
static inline unsigned long mmap_base(void)
{
unsigned long gap = current->signal->rlim[RLIMIT_STACK].rlim_cur;
@@ -46,17 +57,6 @@
return TASK_SIZE - (gap & PAGE_MASK);
}
-static inline int mmap_is_legacy(void)
-{
- if (current->personality & ADDR_COMPAT_LAYOUT)
- return 1;
-
- if (current->signal->rlim[RLIMIT_STACK].rlim_cur == RLIM_INFINITY)
- return 1;
-
- return sysctl_legacy_va_layout;
-}
-
/*
* This function, called very early during the creation of a new
* process VM image, sets up which VM layout function to use:
--
^ permalink raw reply
* [patch 02/10] powerpc: Use new layout for 64bit binaries
From: Anton Blanchard @ 2009-02-22 11:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090222114957.213647384@samba.org>
We currently place mmaps just below the stack on 32bit, but leave them
in the middle of the address space on 64bit:
00100000-00120000 r-xp 00100000 00:00 0 [vdso]
10000000-10010000 r-xp 00000000 08:06 179534 /tmp/sleep
10010000-10020000 rw-p 00000000 08:06 179534 /tmp/sleep
10020000-10130000 rw-p 10020000 00:00 0 [heap]
40000000000-40000030000 r-xp 00000000 08:06 440743 /lib64/ld-2.9.so
40000030000-40000040000 rw-p 00020000 08:06 440743 /lib64/ld-2.9.so
40000050000-400001f0000 r-xp 00000000 08:06 440671 /lib64/libc-2.9.so
400001f0000-40000200000 r--p 00190000 08:06 440671 /lib64/libc-2.9.so
40000200000-40000220000 rw-p 001a0000 08:06 440671 /lib64/libc-2.9.so
40000220000-40008230000 rw-p 40000220000 00:00 0
fffffbc0000-fffffd10000 rw-p fffffeb0000 00:00 0 [stack]
Right now it isn't an issue, but at some stage we will run into mmap or
hugetlb allocation issues. Using the same layout as 32bit gives us a
some breathing room. This matches what x86-64 is doing too.
00100000-00103000 r-xp 00100000 00:00 0 [vdso]
10000000-10001000 r-xp 00000000 08:06 554894 /tmp/test
10010000-10011000 r--p 00000000 08:06 554894 /tmp/test
10011000-10012000 rw-p 00001000 08:06 554894 /tmp/test
10012000-10113000 rw-p 10012000 00:00 0 [heap]
fffefdf7000-ffff7df8000 rw-p fffefdf7000 00:00 0
ffff7df8000-ffff7f97000 r-xp 00000000 08:06 130591 /lib64/libc-2.9.so
ffff7f97000-ffff7fa6000 ---p 0019f000 08:06 130591 /lib64/libc-2.9.so
ffff7fa6000-ffff7faa000 r--p 0019e000 08:06 130591 /lib64/libc-2.9.so
ffff7faa000-ffff7fc0000 rw-p 001a2000 08:06 130591 /lib64/libc-2.9.so
ffff7fc0000-ffff7fc4000 rw-p ffff7fc0000 00:00 0
ffff7fc4000-ffff7fec000 r-xp 00000000 08:06 130663 /lib64/ld-2.9.so
ffff7fee000-ffff7ff0000 rw-p ffff7fee000 00:00 0
ffff7ffa000-ffff7ffb000 rw-p ffff7ffa000 00:00 0
ffff7ffb000-ffff7ffc000 r--p 00027000 08:06 130663 /lib64/ld-2.9.so
ffff7ffc000-ffff7fff000 rw-p 00028000 08:06 130663 /lib64/ld-2.9.so
ffff7fff000-ffff8000000 rw-p ffff7fff000 00:00 0
fffffc59000-fffffc6e000 rw-p ffffffeb000 00:00 0 [stack]
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/mm/mmap.c
===================================================================
--- linux-2.6.orig/arch/powerpc/mm/mmap.c 2009-02-20 13:39:05.000000000 +1100
+++ linux-2.6/arch/powerpc/mm/mmap.c 2009-02-20 13:40:26.000000000 +1100
@@ -48,12 +48,6 @@
static inline int mmap_is_legacy(void)
{
- /*
- * Force standard allocation for 64 bit programs.
- */
- if (!test_thread_flag(TIF_32BIT))
- return 1;
-
if (current->personality & ADDR_COMPAT_LAYOUT)
return 1;
--
^ permalink raw reply
* [patch 01/10] powerpc: Move is_32bit_task
From: Anton Blanchard @ 2009-02-22 11:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090222114957.213647384@samba.org>
Move is_32bit_task into asm/thread_info.h, that allows us to test for
32/64bit tasks without an ugly CONFIG_PPC64 ifdef.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/include/asm/thread_info.h
===================================================================
--- linux-2.6.orig/arch/powerpc/include/asm/thread_info.h 2009-02-20 13:44:37.000000000 +1100
+++ linux-2.6/arch/powerpc/include/asm/thread_info.h 2009-02-20 16:03:02.000000000 +1100
@@ -154,6 +154,13 @@
ti->local_flags |= _TLF_RESTORE_SIGMASK;
set_bit(TIF_SIGPENDING, &ti->flags);
}
+
+#ifdef CONFIG_PPC64
+#define is_32bit_task() (test_thread_flag(TIF_32BIT))
+#else
+#define is_32bit_task() (1)
+#endif
+
#endif /* !__ASSEMBLY__ */
#endif /* __KERNEL__ */
Index: linux-2.6/arch/powerpc/kernel/signal.h
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/signal.h 2009-02-20 13:44:34.000000000 +1100
+++ linux-2.6/arch/powerpc/kernel/signal.h 2009-02-20 13:45:33.000000000 +1100
@@ -39,22 +39,12 @@
#ifdef CONFIG_PPC64
-static inline int is_32bit_task(void)
-{
- return test_thread_flag(TIF_32BIT);
-}
-
extern int handle_rt_signal64(int signr, struct k_sigaction *ka,
siginfo_t *info, sigset_t *set,
struct pt_regs *regs);
#else /* CONFIG_PPC64 */
-static inline int is_32bit_task(void)
-{
- return 1;
-}
-
static inline int handle_rt_signal64(int signr, struct k_sigaction *ka,
siginfo_t *info, sigset_t *set,
struct pt_regs *regs)
--
^ permalink raw reply
* [patch 00/10] PowerPC address space randomisation
From: Anton Blanchard @ 2009-02-22 11:49 UTC (permalink / raw)
To: linuxppc-dev
The following set of patches adds randomisation of mmaps, heap and
position independent executables, and increases the randomisation applied to
the stack on 64bit binaries.
--
^ permalink raw reply
* Re: Lock-up on PPC64
From: malc @ 2009-02-22 8:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0901070105510.4695@linmac.oyster.ru>
On Wed, 7 Jan 2009, malc wrote:
> On Wed, 7 Jan 2009, Benjamin Herrenschmidt wrote:
>
> >
> > > As you wish :) I've written some ad-hoc stuff in the failing path which
> > > manually triggers sysrq and then sends the klogctl output via network
> > > and here it is:
> >
> > Allright, something's unclear to me. What do you mean by the system goes
> > down then ? The kernel appears to be working at least to a certain
> > extent if you manage to trigger a sysrq from userspace... And from what
> > I see, it looks that all processes are somewhere in schedule.
> >
> > So what is precisely your symptom here ?
After writing valgrind tool that was simulating Cell XER.SO syscall
(mis)behaviour (pre ab598b6680f1e74c267d1547ee352f3e1e530f89 that is)
and banging my had against the wall for a while trying to figure out
which of the failing syscalls was responsible, i've tried to be simple
and after only ~30 minutes came up with this, rather short, piece of
code that knocks pre XER.SO patched kernels out cold:
gcc -o xer -x assembler /dev/stdin -nostdlib <<eof
.globl _start
_start:
addis 0,0,0x8000
mtxer 0
addi 0,0,1
sc
eof
--
mailto:av1474@comtv.ru
^ permalink raw reply
* Re: CPU hotplug /sys entries are missing on 2.6.28 [PATCH]
From: Giuliano Pochini @ 2009-02-21 22:21 UTC (permalink / raw)
To: LinuxPPC-dev
In-Reply-To: <20090218221821.ca5d29eb.pochini@shiny.it>
On Wed, 18 Feb 2009 22:18:21 +0100
Giuliano Pochini <pochini@shiny.it> wrote:
> /sys/devices/system/cpu/cpu*/online don't exist anymore.
I think I found the bug. Is this patch ok ?
Signed-off-by: Giuliano Pochini <pochini@shiny.it>
--- linux-2.6.29-rc5/arch/powerpc/platforms/powermac/setup.c__orig 2009-02-14 00:31:30.000000000 +0100
+++ linux-2.6.29-rc5/arch/powerpc/platforms/powermac/setup.c 2009-02-21 22:44:14.000000000 +0100
@@ -746,4 +746,7 @@ define_machine(powermac) {
#if defined(CONFIG_HOTPLUG_CPU) && defined(CONFIG_PPC64)
.cpu_die = pmac_cpu_die,
#endif
+#if defined(CONFIG_HOTPLUG_CPU) && defined(CONFIG_PPC32)
+ .cpu_die = generic_mach_cpu_die,
+#endif
};
--
Giuliano.
^ permalink raw reply
* Re: [PATCH 01/13] sdhci: Add quirk for controllers with no end-of-busy IRQ
From: Pierre Ossman @ 2009-02-21 16:05 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel
In-Reply-To: <20090220173308.GA7583@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 869 bytes --]
On Fri, 20 Feb 2009 20:33:08 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> From: Ben Dooks <ben-linux@fluff.org>
>
> The Samsung SDHCI (and FSL eSDHC) controller block seems to fail
> to generate an INT_DATA_END after the transfer has completed and
> the bus busy state finished.
>
> Changes in e809517f6fa5803a5a1cd56026f0e2190fc13d5c to use the
> new busy method are the cause of the behaviour change.
>
> Signed-off-by: Ben Dooks <ben-linux@fluff.org>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
Any objections to me merging this right away? It is needed for another
controller.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 0/13] FSL eSDHC support
From: Pierre Ossman @ 2009-02-21 16:01 UTC (permalink / raw)
To: avorontsov
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel
In-Reply-To: <20090220173228.GA5091@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 639 bytes --]
On Fri, 20 Feb 2009 20:32:28 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> Hi all,
>
> Some updates for the eSDHC support:
>
I think the patches are coming along nicely. If we can just sort out
the accessors, then it should be ready for -next. It pokes around quite
a bit in the sdhci driver though, so I'd like it to stay there for one
cycle and (hopefully) be merged for 2.6.31.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 12/13] sdhci: Add quirk for controllers with max. block size up to 4096 bytes
From: Pierre Ossman @ 2009-02-21 15:58 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel, Pierre Ossman
In-Reply-To: <20090213144739.GL23889@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]
On Fri, 13 Feb 2009 17:47:39 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> @@ -831,7 +832,12 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data *data)
> sdhci_set_transfer_irqs(host);
>
> /* We do not handle DMA boundaries, so set it to max (512 KiB) */
> - sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, data->blksz), SDHCI_BLOCK_SIZE);
> + if (host->quirks & SDHCI_QUIRK_MAX_BLK_SZ_4096)
> + blksz = data->blksz;
> + else
> + blksz = SDHCI_MAKE_BLKSZ(7, data->blksz);
> +
> + sdhci_writew(host, blksz, SDHCI_BLOCK_SIZE);
> sdhci_writew(host, data->blocks, SDHCI_BLOCK_COUNT);
> }
>
Hmm.. I seem to have overlooked this part previously. I guess they've
basically stripped out the DMA boundary stuff and used the bits for
other things?
At this point I'm leaning more towards simply not supporting their
extended block size. After all, is it ever used?
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 07/13] sdhci: Add support for hosts with strict 32 bit addressing
From: Pierre Ossman @ 2009-02-21 15:58 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel, Pierre Ossman
In-Reply-To: <20090213144722.GG23889@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]
On Fri, 13 Feb 2009 17:47:22 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> SDHCI driver must take special care when working with "triggering"
> registers on hosts with strict 32 bit addressing.
>
> In FSL eSDHC hosts all registers are 32 bit width, writing to the
> first half of any register will cause [undefined?] write the second
> half of the register. That is, 16 bit write to the TRANSFER_MODE
> register, makes hardware see a bogus write to the COMMAND register
> (these two registers are adjacent).
>
> This patch adds SDHCI_QUIRK_32BIT_REGISTERS quirk. When specified,
> the sdhci driver will try to "pack" all dangerous writes into single
> 32 bit write transaction.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
What about the other places where we have 16 and 8 bit registers?
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 05/13] sdhci: Add support for card-detection polling
From: Pierre Ossman @ 2009-02-21 15:58 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel, Pierre Ossman
In-Reply-To: <20090213144718.GE23889@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]
On Fri, 13 Feb 2009 17:47:18 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> @@ -1110,13 +1113,18 @@ static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
>
> host->mrq = mrq;
>
> + if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
> + goto send;
> +
> if (!(sdhci_readl(host, SDHCI_PRESENT_STATE) & SDHCI_CARD_PRESENT)
> || (host->flags & SDHCI_DEVICE_DEAD)) {
> host->mrq->cmd->error = -ENOMEDIUM;
> tasklet_schedule(&host->finish_tasklet);
> - } else
> - sdhci_send_command(host, mrq->cmd);
> -
> + goto out;
> + }
> +send:
> + sdhci_send_command(host, mrq->cmd);
> +out:
> mmiowb();
> spin_unlock_irqrestore(&host->lock, flags);
> }
goto:s seem unnecessary here, and your patch is even incorrect as it
ignores the SDHCI_DEVICE_DEAD flag. Just modify the if-clause and
things will work.
Might want to add a comment also to make it more obvious what the
if-clause does.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 03/13] sdhci: Split card-detection IRQs management from sdhci_init()
From: Pierre Ossman @ 2009-02-21 15:58 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel, Pierre Ossman
In-Reply-To: <20090213144715.GC23889@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]
On Fri, 13 Feb 2009 17:47:15 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> Card detection interrupts should be handled separately as they should
> not be enabled before mmc_add_host() returns and should be disabled
> before calling mmc_remove_host(). The same is for suspend and resume
> routines.
>
> sdhci_init() no longer enables card-detection irqs. Instead, two new
> functions implemented: sdhci_enable_card_detection() and
> sdhci_disable_card_detection().
>
> New sdhci_reinit() call implemented to behave the same way as the old
> sdhci_init().
>
> Also, this patch implements and uses few new helpers to manage IRQs in
> a more conveinient way, that is:
>
> - sdhci_clear_set_irqs()
> - sdhci_unmask_irqs()
> - sdhci_mask_irqs()
> - SDHCI_INT_ALL_MASK constant
>
> sdhci_enable_sdio_irq() converted to these new helpers, plus the
> helpers will be used by the subsequent patches.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
That's a lot of indirection, but fair enough. :)
> @@ -1792,6 +1832,8 @@ int sdhci_add_host(struct sdhci_host *host)
>
> mmc_add_host(mmc);
>
> + sdhci_enable_card_detection(host);
> +
> printk(KERN_INFO "%s: SDHCI controller on %s [%s] using %s%s\n",
> mmc_hostname(mmc), host->hw_name, dev_name(mmc_dev(mmc)),
> (host->flags & SDHCI_USE_ADMA)?"A":"",
There is a small race here, but I'm not sure it's worth dealing with.
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index e907441..45c8309 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -124,6 +124,10 @@
> SDHCI_INT_DATA_AVAIL | SDHCI_INT_SPACE_AVAIL | \
> SDHCI_INT_DATA_TIMEOUT | SDHCI_INT_DATA_CRC | \
> SDHCI_INT_DATA_END_BIT)
> +#define SDHCI_INT_ALL_MASK (SDHCI_INT_CMD_MASK | SDHCI_INT_DATA_MASK | \
> + SDHCI_INT_CARD_INSERT | SDHCI_INT_CARD_REMOVE | \
> + SDHCI_INT_CARD_INT | SDHCI_INT_ERROR | SDHCI_INT_BUS_POWER | \
> + SDHCI_INT_ACMD12ERR | SDHCI_INT_ADMA_ERROR)
>
In the context this is used, why not just use (unsigned)-1?
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox