52xx build error
I get that with my current stuff: cc1: warnings being treated as errors In file included from /home/benh/linux-powerpc-test/arch/powerpc/platforms/52xx/mpc52xx_common.c:19: /home/benh/linux-powerpc-test/include/linux/of_gpio.h:74: error: ‘struct gpio_chip’ declared inside parameter list /home/benh/linux-powerpc-test/include/linux/of_gpio.h:74: error: its scope is only this definition or declaration, which is probably not what you want /home/benh/linux-powerpc-test/include/linux/of_gpio.h:75: error: ‘struct gpio_chip’ declared inside parameter list CC mm/bootmem.o make[3]: *** [arch/powerpc/platforms/52xx/mpc52xx_common.o] Error 1 make[3]: *** Waiting for unfinished jobs Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [powerpc] Wire up fanotify_init, fanotify_mark, prlimit64 syscalls
On Mon, 2010-08-23 at 15:52 +0200, Arnd Bergmann wrote: On Friday 20 August 2010, Andreas Schwab wrote: See arch/powerpc/platforms/cell/spu_callbacks.c. * 4. They are optional and we can't rely on them being *linked into the kernel. Unfortunately, the cond_syscall *helper does not work here as it does not add the necessary *opd symbols: Right. I should blame the person that wrote this comment. If only I could remember who that was. Regardless of the outcome of that, I'm merging Andreas patch. We can always add SPU bindings if we feel like it later. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here's a few powerpc bits fixes for 2.6.36, some of them for some of the new stuff that went in, along with the powerpc rwsem update to atomic_long_t (not yet moved to asm-generic) and wiring up of some new syscalls. Cheers, Ben. The following changes since commit d1b113bb028999e82a8528e1484be8c23fb5a7d9: Linus Torvalds (1): Merge git://git.kernel.org/.../davem/net-2.6 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git master Anatolij Gustschin (1): powerpc: Fix typo in uImage target Andreas Schwab (3): powerpc: Wire up fanotify_init, fanotify_mark, prlimit64 syscalls via-pmu: Add compat_pmu_ioctl powerpc: Fix config dependency problem with MPIC_U3_HT_IRQS Anton Blanchard (4): powerpc/mm: Fix vsid_scrample typo powerpc/kdump: Stop all other CPUs before running crash handlers powerpc: Inline ppc64_runlatch_off powerpc: Fix bogus it_blocksize in VIO iommu code Benjamin Herrenschmidt (2): Merge remote branch 'jwb/merge' into merge powerpc: Make rwsem use long type Dave Kleikamp (4): powerpc/47x: Make sure mcsr is cleared before enabling machine check interrupts powerpc/47x: Remove redundant line from cputable.c powerpc/4xx: Index interrupt stacks by physical cpu powerpc/47x: Add an isync before the tlbivax instruction Denis Kirjanov (1): powerpc: Use is_32bit_task() helper to test 32 bit binary Grant Likely (1): powerpc/pci: Fix checking for child bridges in PCI code. Julia Lawall (3): powerpc/powermac: Drop unnecessary of_node_put powerpc/powermac: Drop unnecessary null test powerpc/pci: Drop unnecessary null test Matt Evans (1): powerpc: Initialise paca-kstack before early_setup_secondary Nathan Fontenot (1): powerpc: Correct smt_enabled=X boot option for 2 threads per core Rupjyoti Sarmah (1): powerpc/4xx: Device tree update for the 460ex DWC SATA Signed-off-by: Darren Hart (3): powerpc: Re-enable preemption before cpu_die() powerpc: Silence __cpu_up() under normal operation powerpc: Silence xics_migrate_irqs_away() during cpu offline Sonny Rao (1): powerpc: Export memstart_addr and kernstart_addr on ppc64 arch/powerpc/Makefile |2 +- arch/powerpc/boot/dts/canyonlands.dts |8 arch/powerpc/include/asm/mmu-hash64.h |2 +- arch/powerpc/include/asm/reg.h|9 - arch/powerpc/include/asm/rwsem.h | 64 + arch/powerpc/include/asm/systbl.h |3 + arch/powerpc/include/asm/unistd.h |5 ++- arch/powerpc/kernel/cputable.c|1 - arch/powerpc/kernel/crash.c | 24 ++- arch/powerpc/kernel/head_44x.S|4 ++ arch/powerpc/kernel/head_64.S |6 +- arch/powerpc/kernel/idle.c|2 +- arch/powerpc/kernel/irq.c | 16 --- arch/powerpc/kernel/pci_of_scan.c |2 +- arch/powerpc/kernel/process.c | 20 - arch/powerpc/kernel/setup_32.c|9 ++-- arch/powerpc/kernel/setup_64.c| 63 arch/powerpc/kernel/smp.c |4 +- arch/powerpc/kernel/sys_ppc32.c |8 arch/powerpc/kernel/vio.c |3 +- arch/powerpc/mm/init_64.c |2 + arch/powerpc/mm/tlb_nohash_low.S |1 + arch/powerpc/platforms/Kconfig|3 +- arch/powerpc/platforms/cell/iommu.c |2 +- arch/powerpc/platforms/iseries/iommu.c|2 +- arch/powerpc/platforms/powermac/feature.c |3 +- arch/powerpc/platforms/powermac/pci.c |2 - arch/powerpc/platforms/pseries/iommu.c|8 ++-- arch/powerpc/platforms/pseries/smp.c | 11 +++-- arch/powerpc/platforms/pseries/xics.c |6 ++- drivers/macintosh/via-pmu.c | 42 +++ 31 files changed, 219 insertions(+), 118 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [powerpc] Wire up fanotify_init, fanotify_mark, prlimit64 syscalls
On Tuesday 24 August 2010, Benjamin Herrenschmidt wrote: On Mon, 2010-08-23 at 15:52 +0200, Arnd Bergmann wrote: On Friday 20 August 2010, Andreas Schwab wrote: See arch/powerpc/platforms/cell/spu_callbacks.c. * 4. They are optional and we can't rely on them being *linked into the kernel. Unfortunately, the cond_syscall *helper does not work here as it does not add the necessary *opd symbols: Right. I should blame the person that wrote this comment. If only I could remember who that was. Regardless of the outcome of that, I'm merging Andreas patch. We can always add SPU bindings if we feel like it later. Sorry, I should have added a ';-)' or been clearer. The patch is good, I wrote the comment that Andreas quoted and it's probably my own fault that we never found a way to handle syscalls like this correctly from the SPU. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] gpiolib: Add 'struct gpio_chip' forward declaration for !GPIOLIB case
With CONFIG_GPIOLIB=n, the 'struct gpio_chip' is not declared, so the following pops up on PowerPC: cc1: warnings being treated as errors In file included from arch/powerpc/platforms/52xx/mpc52xx_common.c:19: include/linux/of_gpio.h:74: warning: 'struct gpio_chip' declared inside parameter list include/linux/of_gpio.h:74: warning: its scope is only this definition or declaration, which is probably not what you want include/linux/of_gpio.h:75: warning: 'struct gpio_chip' declared inside parameter list make[2]: *** [arch/powerpc/platforms/52xx/mpc52xx_common.o] Error 1 This patch fixes the issue by providing the proper forward declaration. Signed-off-by: Anton Vorontsov cbouatmai...@gmail.com --- On Tue, Aug 24, 2010 at 04:26:08PM +1000, Benjamin Herrenschmidt wrote: I get that with my current stuff: cc1: warnings being treated as errors In file included from [..]/mpc52xx_common.c:19: of_gpio.h:74: error: ‘struct gpio_chip’ declared inside parameter list [...] make[3]: *** Waiting for unfinished jobs That's because with GPIOCHIP=n no one declares struct gpio_chip. It should be either of_gpio.h or gpio.h. Let's make it gpio.h, as this feels more generic, and we already have some !GPIOLIB handling in there. include/linux/gpio.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/linux/gpio.h b/include/linux/gpio.h index 03f616b..85207d2 100644 --- a/include/linux/gpio.h +++ b/include/linux/gpio.h @@ -15,6 +15,12 @@ struct device; /* + * Some code might rely on the declaration. Still, it is illegal + * to dereference it for !GPIOLIB case. + */ +struct gpio_chip; + +/* * Some platforms don't support the GPIO programming interface. * * In case some driver uses it anyway (it should normally have -- 1.7.0.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 64-bit ppc rwsem
On Tuesday 24 August 2010, Benjamin Herrenschmidt wrote: On Mon, 2010-08-23 at 15:18 -0700, David Miller wrote: I've seen drivers in the past do trylocks at interrupt time ... tho I agree it sucks. Recently there was a thread where this was declared absolutely illegal. Maybe it was allowed, or sort-of worked before, and that's why it's accounted for with IRQ disables in some implementations. I don't know. Ok, I'm happy to say it's a big no-no then. Arnd, do you want to take over the moving to asm-generic and take care of the spinlock case as well ? I can send Linus the first patch that changes powerpc to use atomic_long now along with a few other things I have pending, then you can pickup from there. Or do you want me to continue pushing my patch as-is and we can look at cleaning up the spinlock case separately ? I'm currently doing too many things at once, please push in your existing patch for now, we can continue from there. For the asm-generic patch: Acked-by: Arnd Bergmann a...@arndb.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
Hello! I'm curious if its possible to do the PTP hardware offset/adjustment calculation in a module internally to the kernel? That would allow the PPS interface to still be used to sync the system time, and not expose additional interfaces. Just my 2 cents on this issue. PTP is very often used in embedded systems, where the PTP timestamps will go into some dedicated hardware, for instance an FPGA. I'm currently working on a project where it is not necessary to adjust the Linux system time via PTP (although it would be a nice to have), but we only need the timestamps from the PHY to put them into our FPGA device. So we need some kind of API to access the PTP timestamp registers. Kind regards, Stephan smime.p7s Description: S/MIME Cryptographic Signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] powerpc: Clear cpu_sibling_map in cpu_die
On 08/24/2010 12:24 AM, Benjamin Herrenschmidt wrote:
On Wed, 2010-08-11 at 15:34 -0500, Brian King wrote:
While testing CPU DLPAR, the following problem was discovered.
We were DLPAR removing the first CPU, which in this case was
logical CPUs 0-3. CPUs 0-2 were already marked offline and
we were in the process of offlining CPU 3. After marking
the CPU inactive and offline in cpu_disable, but before the
cpu was completely idle (cpu_die), we ended up in __make_request
on CPU 3. There we looked at the topology map to see which CPU
to complete the I/O on and found no CPUs in the cpu_sibling_map.
This resulted in the block layer setting the completion cpu
to be NR_CPUS, which then caused an oops when we tried to
complete the I/O.
Fix this by delaying clearing the sibling map of the cpu we
are offlining for the cpu we are offlining until cpu_die.
So I'm not getting a clear mental picture of the situation, sorry about
that.
We are offlining CPU 3, and we have already marked it inactive and
online, so how come we end up in __make_request() on it at this stage
I'm not sure about that. My thought was that until we get into cpu_die,
the cpu could still be executing code.
and shouldn't it be the block layer that notices that it's targeting an
offlined CPU ?
It could be easily fixed in blk_cpu_to_group as well. I'll look into
this.
IE. I have doubts about leaving a CPU in the sibling map which isn't
online... Wouldn't we end up scheduling things to it after it's
supposed to have freed itself of everything (timers, workqueues,
etc...) ?
I was assuming this wouldn't happen since the cpu is no longer online.
Thanks,
Brian
As I said, I'm probably missing a part of the puzzle ..
Ben.
Signed-off-by: Brian King brk...@linux.vnet.ibm.com
---
arch/powerpc/kernel/smp.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff -puN arch/powerpc/kernel/smp.c~powerpc_sibling_map_offline
arch/powerpc/kernel/smp.c
--- linux-2.6/arch/powerpc/kernel/smp.c~powerpc_sibling_map_offline
2010-08-09 16:49:47.0 -0500
+++ linux-2.6-bjking1/arch/powerpc/kernel/smp.c 2010-08-09
16:49:47.0 -0500
@@ -598,8 +598,11 @@ int __cpu_disable(void)
/* Update sibling maps */
base = cpu_first_thread_in_core(cpu);
for (i = 0; i threads_per_core; i++) {
-cpumask_clear_cpu(cpu, cpu_sibling_mask(base + i));
-cpumask_clear_cpu(base + i, cpu_sibling_mask(cpu));
+if ((base + i) != cpu) {
+cpumask_clear_cpu(cpu, cpu_sibling_mask(base + i));
+cpumask_clear_cpu(base + i, cpu_sibling_mask(cpu));
+}
+
cpumask_clear_cpu(cpu, cpu_core_mask(base + i));
cpumask_clear_cpu(base + i, cpu_core_mask(cpu));
}
@@ -641,6 +644,8 @@ void cpu_hotplug_driver_unlock()
void cpu_die(void)
{
+cpumask_clear_cpu(smp_processor_id(),
cpu_sibling_mask(smp_processor_id()));
+
if (ppc_md.cpu_die)
ppc_md.cpu_die();
}
_
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Check end of stack canary at oops time
Add a check for the stack canary when we oops, similar to x86. This should make
it clear that we overran our stack:
Unable to handle kernel paging request for data at address 0x24652f63700ac689
Faulting instruction address: 0xc0063d24
Thread overran stack, or stack corrupted
Signed-off-by: Anton Blanchard an...@samba.org
---
Index: powerpc.git/arch/powerpc/mm/fault.c
===
--- powerpc.git.orig/arch/powerpc/mm/fault.c2010-08-25 08:41:08.230086186
+1000
+++ powerpc.git/arch/powerpc/mm/fault.c 2010-08-25 09:12:38.276553103 +1000
@@ -30,6 +30,7 @@
#include linux/kprobes.h
#include linux/kdebug.h
#include linux/perf_event.h
+#include linux/magic.h
#include asm/firmware.h
#include asm/page.h
@@ -385,6 +386,7 @@ do_sigbus:
void bad_page_fault(struct pt_regs *regs, unsigned long address, int sig)
{
const struct exception_table_entry *entry;
+ unsigned long *stackend;
/* Are we prepared to handle this fault? */
if ((entry = search_exception_tables(regs-nip)) != NULL) {
@@ -413,5 +415,9 @@ void bad_page_fault(struct pt_regs *regs
printk(KERN_ALERT Faulting instruction address: 0x%08lx\n,
regs-nip);
+ stackend = end_of_stack(current);
+ if (current != init_task *stackend != STACK_END_MAGIC)
+ printk(KERN_ALERT Thread overran stack, or stack corrupted\n);
+
die(Kernel access of bad area, regs, sig);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: kdump: Override crash_free_reserved_phys_range to avoid freeing RTAS
The crashkernel region will almost always overlap RTAS. If we free the
crashkernel region via echo 0 /sys/kernel/kexec_crash_size then we will
free RTAS and the machine will crash in confusing and exciting ways.
Override crash_free_reserved_phys_range and check for overlap with RTAS.
Signed-off-by: Anton Blanchard an...@samba.org
---
Index: powerpc.git/arch/powerpc/kernel/crash_dump.c
===
--- powerpc.git.orig/arch/powerpc/kernel/crash_dump.c 2010-08-24
09:24:32.219643256 +1000
+++ powerpc.git/arch/powerpc/kernel/crash_dump.c2010-08-24
09:46:22.826868330 +1000
@@ -19,6 +19,7 @@
#include asm/prom.h
#include asm/firmware.h
#include asm/uaccess.h
+#include asm/rtas.h
#ifdef DEBUG
#include asm/udbg.h
@@ -141,3 +142,35 @@ ssize_t copy_oldmem_page(unsigned long p
return csize;
}
+
+#ifdef CONFIG_PPC_RTAS
+/*
+ * The crashkernel region will almost always overlap the RTAS region, so
+ * we have to be careful when shrinking the crashkernel region.
+ */
+void crash_free_reserved_phys_range(unsigned long begin, unsigned long end)
+{
+ unsigned long addr;
+ const u32 *basep, *sizep;
+ unsigned int rtas_start = 0, rtas_end = 0;
+
+ basep = of_get_property(rtas.dev, linux,rtas-base, NULL);
+ sizep = of_get_property(rtas.dev, rtas-size, NULL);
+
+ if (basep sizep) {
+ rtas_start = *basep;
+ rtas_end = *basep + *sizep;
+ }
+
+ for (addr = begin; addr end; addr += PAGE_SIZE) {
+ /* Does this page overlap with the RTAS region? */
+ if (addr = rtas_end ((addr + PAGE_SIZE) rtas_start))
+ continue;
+
+ ClearPageReserved(pfn_to_page(addr PAGE_SHIFT));
+ init_page_count(pfn_to_page(addr PAGE_SHIFT));
+ free_page((unsigned long)__va(addr));
+ totalram_pages++;
+ }
+}
+#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
On ppc64 the crashkernel region almost always overlaps an area of firmware.
This works fine except when using the sysfs interface to reduce the kdump
region. If we free the firmware area we are guaranteed to crash.
Rename free_reserved_phys_range to crash_free_reserved_phys_range and make
it a weak function so we can override it.
Signed-off-by: Anton Blanchard an...@samba.org
---
Index: powerpc.git/kernel/kexec.c
===
--- powerpc.git.orig/kernel/kexec.c 2010-08-25 10:12:11.493863566 +1000
+++ powerpc.git/kernel/kexec.c 2010-08-25 10:12:35.907264327 +1000
@@ -1097,7 +1097,8 @@ size_t crash_get_memory_size(void)
return size;
}
-static void free_reserved_phys_range(unsigned long begin, unsigned long end)
+void __weak crash_free_reserved_phys_range(unsigned long begin,
+ unsigned long end)
{
unsigned long addr;
@@ -1133,7 +1134,7 @@ int crash_shrink_memory(unsigned long ne
start = roundup(start, PAGE_SIZE);
end = roundup(start + new_size, PAGE_SIZE);
- free_reserved_phys_range(end, crashk_res.end);
+ crash_free_reserved_phys_range(end, crashk_res.end);
if ((start == end) (crashk_res.parent != NULL))
release_resource(crashk_res);
Index: powerpc.git/include/linux/kexec.h
===
--- powerpc.git.orig/include/linux/kexec.h 2010-08-25 10:12:11.483862172
+1000
+++ powerpc.git/include/linux/kexec.h 2010-08-25 10:12:13.664166570 +1000
@@ -208,6 +208,7 @@ int __init parse_crashkernel(char *cmdli
unsigned long long *crash_size, unsigned long long *crash_base);
int crash_shrink_memory(unsigned long new_size);
size_t crash_get_memory_size(void);
+void crash_free_reserved_phys_range(unsigned long begin, unsigned long end);
#else /* !CONFIG_KEXEC */
struct pt_regs;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Check end of stack canary at oops time
On Wed, 2010-08-25 at 09:15 +1000, Anton Blanchard wrote:
Add a check for the stack canary when we oops, similar to x86. This should
make
it clear that we overran our stack:
Unable to handle kernel paging request for data at address 0x24652f63700ac689
Faulting instruction address: 0xc0063d24
Thread overran stack, or stack corrupted
Signed-off-by: Anton Blanchard an...@samba.org
---
Index: powerpc.git/arch/powerpc/mm/fault.c
===
--- powerpc.git.orig/arch/powerpc/mm/fault.c 2010-08-25 08:41:08.230086186
+1000
+++ powerpc.git/arch/powerpc/mm/fault.c 2010-08-25 09:12:38.276553103
+1000
@@ -30,6 +30,7 @@
#include linux/kprobes.h
#include linux/kdebug.h
#include linux/perf_event.h
+#include linux/magic.h
#include asm/firmware.h
#include asm/page.h
@@ -385,6 +386,7 @@ do_sigbus:
void bad_page_fault(struct pt_regs *regs, unsigned long address, int sig)
{
const struct exception_table_entry *entry;
+ unsigned long *stackend;
/* Are we prepared to handle this fault? */
if ((entry = search_exception_tables(regs-nip)) != NULL) {
@@ -413,5 +415,9 @@ void bad_page_fault(struct pt_regs *regs
printk(KERN_ALERT Faulting instruction address: 0x%08lx\n,
regs-nip);
+ stackend = end_of_stack(current);
+ if (current != init_task *stackend != STACK_END_MAGIC)
+ printk(KERN_ALERT Thread overran stack, or stack corrupted\n);
The check for init is just because we haven't set the magic value for
init's stack right? But we could.
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
On Tue, 2010-08-24 at 15:15 +1000, Michael Neuling wrote: Do some 32 bit processors need this? In 32 bit before the merge, we use to have code that did: #if defined(CONFIG_4xx) || defined(CONFIG_E500) #define cvt_fd without save/restore fpscr #else #define cvt_fd with save/restore fpscr #end if Kumar; does this ring any bells? I don't see anything in the various 440 docs I have at hand that would hint at lfd/stfs adffecting FPSCR. The way the ifdefs are, it's the other way around. 4xx procs don't need to save/restore fpscr and others do. Right, my bad. In any case, Paulus reckons it's all his mistake and we really never need to save/restore fpscr. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
In message 1282699836.22370.566.ca...@pasglop you wrote: On Tue, 2010-08-24 at 15:15 +1000, Michael Neuling wrote: Do some 32 bit processors need this? In 32 bit before the merge, we use to have code that did: #if defined(CONFIG_4xx) || defined(CONFIG_E500) #define cvt_fd without save/restore fpscr #else #define cvt_fd with save/restore fpscr #end if Kumar; does this ring any bells? I don't see anything in the various 440 docs I have at hand that would hint at lfd/stfs adffecting FPSCR. The way the ifdefs are, it's the other way around. 4xx procs don't need to save/restore fpscr and others do. Right, my bad. In any case, Paulus reckons it's all his mistake and we really never need to save/restore fpscr. ACK :-P Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Check end of stack canary at oops time
Hi, The check for init is just because we haven't set the magic value for init's stack right? But we could. Yeah, it's similar to what x86 are doing now: commit 0e7810be30f66e9f430c4ce2cd3b14634211690f Author: Jan Beulich jbeul...@novell.com Date: Fri Nov 20 14:00:14 2009 + x86: Suppress stack overrun message for init_task init_task doesn't get its stack end location set to STACK_END_MAGIC, and hence the message is confusing rather than helpful in this case. Adding it directly to init_task would be nice but I suspect we'd either have to make assumptions about end_of_stack in our code or move the canary into the thread_info (so we can statically allocate it via INIT_THREAD_INFO()) or do it at runtime somewhere, hopefully early enough that we couldn't take an oops. Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
Anton Blanchard an...@samba.org writes: On ppc64 the crashkernel region almost always overlaps an area of firmware. This works fine except when using the sysfs interface to reduce the kdump region. If we free the firmware area we are guaranteed to crash. That is ppc64 bug. firmware should not be in the reserved region. Any random kernel like thing can be put in to that region at any valid address and the fact that shrinking the region frees your firmware means that using that region could also stomp your firmware (which I assume would be a bad thing). So please fix the ppc64 reservation. Eric ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
