* [PATCH] Restrict stack space reservation to rlimit
From: Michael Neuling @ 2010-02-08 0:07 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds
Cc: linux-kernel, aeb, James Morris, miltonm, Oleg Nesterov,
linuxppc-dev, Paul Mackerras, Alexander Viro, WANG Cong,
linux-fsdevel, Serge Hallyn, Ingo Molnar, stable, Anton Blanchard
In-Reply-To: <10125.1265451732@neuling.org>
apkm, linus: this or something like it needs to go into 2.6.33 (& 32) to
fix 'ulimit -s'.
Mikey
[PATCH] Restrict stack space reservation to rlimit
When reserving stack space for a new process, make sure we're not
attempting to allocate more than rlimit allows.
Also, reserve the same stack size independent of page size.
This fixes a bug unmasked by fc63cf237078c86214abcb2ee9926d8ad289da9b
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: stable@kernel.org
---
fs/exec.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
Index: clone1/fs/exec.c
===================================================================
--- clone1.orig/fs/exec.c
+++ clone1/fs/exec.c
@@ -554,7 +554,7 @@ static int shift_arg_pages(struct vm_are
return 0;
}
-#define EXTRA_STACK_VM_PAGES 20 /* random */
+#define EXTRA_STACK_VM_SIZE 81920UL /* randomly 20 4K pages */
/*
* Finalizes the stack vm_area_struct. The flags and permissions are updated,
@@ -627,10 +627,13 @@ int setup_arg_pages(struct linux_binprm
goto out_unlock;
}
+ stack_base = min(EXTRA_STACK_VM_SIZE,
+ current->signal->rlim[RLIMIT_STACK].rlim_cur) -
+ PAGE_SIZE;
#ifdef CONFIG_STACK_GROWSUP
- stack_base = vma->vm_end + EXTRA_STACK_VM_PAGES * PAGE_SIZE;
+ stack_base = vma->vm_end + stack_base;
#else
- stack_base = vma->vm_start - EXTRA_STACK_VM_PAGES * PAGE_SIZE;
+ stack_base = vma->vm_start - stack_base;
#endif
ret = expand_stack(vma, stack_base);
if (ret)
^ permalink raw reply
* [PATCH] Restrict stack space reservation to rlimit
From: Michael Neuling @ 2010-02-08 0:28 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds
Cc: linux-kernel, aeb, James Morris, miltonm, Oleg Nesterov,
linuxppc-dev, Paul Mackerras, Ollie Wild, WANG Cong,
linux-fsdevel, Serge Hallyn, Ingo Molnar, stable, Anton Blanchard,
Alexander Viro
In-Reply-To: <18033.1265587672@neuling.org>
When reserving stack space for a new process, make sure we're not
attempting to allocate more than rlimit allows.
Also, reserve the same stack size independent of page size.
This fixes a bug cause by b6a2fea39318e43fee84fa7b0b90d68bed92d2ba
"mm: variable length argument support" and unmasked by
fc63cf237078c86214abcb2ee9926d8ad289da9b
"exec: setup_arg_pages() fails to return errors".
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: stable@kernel.org
---
Update commit message to include patch name and SHA1 of related
patches.
fs/exec.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
Index: clone1/fs/exec.c
===================================================================
--- clone1.orig/fs/exec.c
+++ clone1/fs/exec.c
@@ -554,7 +554,7 @@ static int shift_arg_pages(struct vm_are
return 0;
}
-#define EXTRA_STACK_VM_PAGES 20 /* random */
+#define EXTRA_STACK_VM_SIZE 81920UL /* randomly 20 4K pages */
/*
* Finalizes the stack vm_area_struct. The flags and permissions are updated,
@@ -627,10 +627,13 @@ int setup_arg_pages(struct linux_binprm
goto out_unlock;
}
+ stack_base = min(EXTRA_STACK_VM_SIZE,
+ current->signal->rlim[RLIMIT_STACK].rlim_cur) -
+ PAGE_SIZE;
#ifdef CONFIG_STACK_GROWSUP
- stack_base = vma->vm_end + EXTRA_STACK_VM_PAGES * PAGE_SIZE;
+ stack_base = vma->vm_end + stack_base;
#else
- stack_base = vma->vm_start - EXTRA_STACK_VM_PAGES * PAGE_SIZE;
+ stack_base = vma->vm_start - stack_base;
#endif
ret = expand_stack(vma, stack_base);
if (ret)
^ permalink raw reply
* [PATCH] powerpc: Add last sysfs file and dump of ftrace buffer to oops printout
From: Anton Blanchard @ 2010-02-08 0:44 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Add printout of last accessed sysfs file, added to x86 in
ae87221d3ce49d9de1e43756da834fd0bf05a2ad (sysfs: crash debugging)
Also add the notify_die hook that allows us to print out the ftrace
buffer on oops. This is useful in conjunction with ftrace function_graph:
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=128 NUMA pSeries
last sysfs file: /sys/class/net/tunl0/type
Dumping ftrace buffer:
...
0) | .sysrq_handle_crash() {
0) 0.476 us | .hash_page();
0) 0.488 us | .xmon_fault_handler();
0) | .bad_page_fault() {
0) | .search_exception_tables() {
0) 0.590 us | .search_module_extables();
0) 2.546 us | }
0) | .printk() {
0) | .vprintk() {
0) 0.488 us | ._raw_spin_lock();
0) 0.572 us | .emit_log_char();
Showing the function graph of a sysrq-c crash.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/traps.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/traps.c 2010-02-08 11:15:51.463071942 +1100
+++ powerpc.git/arch/powerpc/kernel/traps.c 2010-02-08 11:17:29.914321833 +1100
@@ -146,6 +146,11 @@ int die(const char *str, struct pt_regs
#endif
printk("%s\n", ppc_md.name ? ppc_md.name : "");
+ sysfs_printk_last_file();
+ if (notify_die(DIE_OOPS, str, regs, err, 255,
+ SIGSEGV) == NOTIFY_STOP)
+ return 1;
+
print_modules();
show_regs(regs);
} else {
^ permalink raw reply
* powerpc/pseries: Fix kexec regression caused by CPPR tracking
From: Mark Nelson @ 2010-02-08 2:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <201002011712.58684.markn@au1.ibm.com>
The code to track the CPPR values added by commit
49bd3647134ea47420067aea8d1401e722bf2aac ("powerpc/pseries: Track previous
CPPR values to correctly EOI interrupts") broke kexec on pseries because
the kexec code in xics.c calls xics_set_cpu_priority() before the IPI has
been EOI'ed. This wasn't a problem previously but it now triggers a BUG_ON
in xics_set_cpu_priority() because os_cppr->index isn't 0:
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=128 NUMA
kernel BUG at arch/powerpc/platforms/pseries/xics.c:791!
pSeries
Modules linked in: ehea dm_mirror dm_region_hash dm_log dm_zero dm_snapshot parport_pc parport dm_multipath autofs4
NIP: c0000000000461bc LR: c000000000046260 CTR: c00000000004bc08
REGS: c00000000fffb770 TRAP: 0700 Not tainted (2.6.33-rc6-autokern1)
MSR: 8000000000021032 <ME,CE,IR,DR> CR: 48000022 XER: 00000001
TASK = c000000000aef700[0] 'swapper' THREAD: c000000000bcc000 CPU: 0
GPR00: 0000000000000001 c00000000fffb9f0 c000000000bcc9e8 0000000000000000
GPR04: 0000000000000000 0000000000000000 00000000000000dc 0000000000000002
GPR08: c0000000040036e8 c000000004002e40 0000000000000898 0000000000000000
GPR12: 0000000000000002 c000000000bf8480 0000000003500000 c000000000792f28
GPR16: c0000000007915e0 0000000000000000 0000000000419000 0000000003da8990
GPR20: c0000000008a8990 0000000000000010 c000000000ae92c0 0000000000000010
GPR24: 0000000000000000 c000000000be2380 0000000000000000 0000000000200200
GPR28: 0000000000000001 0000000000000001 c000000000b249e8 0000000000000000
NIP [c0000000000461bc] .xics_set_cpu_priority+0x38/0xb8
LR [c000000000046260] .xics_teardown_cpu+0x24/0xa4
Call Trace:
[c00000000fffb9f0] [00000000ffffebf3] 0xffffebf3 (unreliable)
[c00000000fffba60] [c000000000046260] .xics_teardown_cpu+0x24/0xa4
[c00000000fffbae0] [c000000000046330] .xics_kexec_teardown_cpu+0x18/0xb4
[c00000000fffbb60] [c00000000004a150] .pseries_kexec_cpu_down_xics+0x20/0x38
[c00000000fffbbf0] [c00000000002e5b8] .kexec_smp_down+0x48/0x7c
[c00000000fffbc70] [c0000000000b2dd0] .generic_smp_call_function_interrupt+0xf4/0x1b4
[c00000000fffbd20] [c00000000002aed0] .smp_message_recv+0x48/0x100
[c00000000fffbda0] [c000000000046ae0] .xics_ipi_dispatch+0x84/0x148
[c00000000fffbe30] [c0000000000d62dc] .handle_IRQ_event+0xc8/0x248
[c00000000fffbf00] [c0000000000d8eb4] .handle_percpu_irq+0x80/0xf4
[c00000000fffbf90] [c000000000029048] .call_handle_irq+0x1c/0x2c
[c000000000bcfa30] [c00000000000ec84] .do_IRQ+0x1b8/0x2a4
[c000000000bcfae0] [c000000000004804] hardware_interrupt_entry+0x1c/0x98
Fix this problem by setting the index on the CPPR stack to 0 before calling
xics_set_cpu_priority() in xics_teardown_cpu().
Also make it clear that we only want to set the priority when there's just
one CPPR value in the stack, and enforce it by updating the value of
os_cppr->stack[0] rather than os_cppr->stack[os_cppr->index].
While we're at it change the BUG_ON to a WARN_ON.
Reported-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
---
Ben, if it's not too late for 2.6.33 this would be really nice to have
as without it we can't kexec on pseries.
arch/powerpc/platforms/pseries/xics.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
Index: upstream/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- upstream.orig/arch/powerpc/platforms/pseries/xics.c
+++ upstream/arch/powerpc/platforms/pseries/xics.c
@@ -784,9 +784,13 @@ static void xics_set_cpu_priority(unsign
{
struct xics_cppr *os_cppr = &__get_cpu_var(xics_cppr);
- BUG_ON(os_cppr->index != 0);
+ /*
+ * we only really want to set the priority when there's
+ * just one cppr value on the stack
+ */
+ WARN_ON(os_cppr->index != 0);
- os_cppr->stack[os_cppr->index] = cppr;
+ os_cppr->stack[0] = cppr;
if (firmware_has_feature(FW_FEATURE_LPAR))
lpar_cppr_info(cppr);
@@ -821,8 +825,14 @@ void xics_setup_cpu(void)
void xics_teardown_cpu(void)
{
+ struct xics_cppr *os_cppr = &__get_cpu_var(xics_cppr);
int cpu = smp_processor_id();
+ /*
+ * we have to reset the cppr index to 0 because we're
+ * not going to return from the IPI
+ */
+ os_cppr->index = 0;
xics_set_cpu_priority(0);
/* Clear any pending IPI request */
^ permalink raw reply
* Re: [PATCH 01/10] arch/powerpc: Fix continuation line formats
From: Benjamin Herrenschmidt @ 2010-02-08 3:46 UTC (permalink / raw)
To: Joe Perches; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <1265049037.25140.301.camel@Joe-Laptop.home>
On Mon, 2010-02-01 at 10:30 -0800, Joe Perches wrote:
> On Mon, 2010-02-01 at 13:16 +1100, Benjamin Herrenschmidt wrote:
> > On Sun, 2010-01-31 at 12:02 -0800, Joe Perches wrote:
> > > String constants that are continued on subsequent lines with \
> > > are not good.
> > > Signed-off-by: Joe Perches <joe@perches.com>
> > You want me to take that in the powerpc tree ?
>
> Yes please.
>
> > A minor glitch below tho...
> > > @@ -349,7 +349,7 @@ static int __init nvram_create_os_partition(void)
> > > rc = ppc_md.nvram_write((char *)&seq_init, sizeof(seq_init), &tmp_index);
> > > if (rc <= 0) {
> > > printk(KERN_ERR "nvram_create_os_partition: nvram_write "
> > > - "failed (%d)\n", rc);
> > > + "failed (%d)\n", rc);
> > > return rc;
> > > }
> >
> > The above is objectionable :-)
>
> Can you drop that section or do you need another patch?
I'll sort it out. Thanks.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: fix ioremap_flags() with book3e pte definition
From: Benjamin Herrenschmidt @ 2010-02-08 4:21 UTC (permalink / raw)
To: Li Yang; +Cc: galak, linuxppc-dev
In-Reply-To: <1265302382-15142-1-git-send-email-leoli@freescale.com>
On Fri, 2010-02-05 at 00:53 +0800, Li Yang wrote:
> We can't just clear the user read permission in book3e pte, because
> that will also clear supervisor read permission. This surely isn't
> desired. Fix the problem by adding the supervisor read back.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/mm/pgtable_32.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index cb96cb2..aff7c04 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -144,6 +144,11 @@ ioremap_flags(phys_addr_t addr, unsigned long size, unsigned long flags)
> /* we don't want to let _PAGE_USER and _PAGE_EXEC leak out */
> flags &= ~(_PAGE_USER | _PAGE_EXEC);
>
> +#if defined(CONFIG_FSL_BOOKE) && defined(CONFIG_PTE_64BIT)
> + /* supervisor read permission has just been cleared, add back */
> + flags |= _PAGE_BAP_SR;
> +#endif
> +
So this is a bit fishy indeed. pgtable_64.c seems to have the same
problem in fact.
It boils down to the "hack" I have in the new PTE format which consists
of having _SR be part of _PAGE_USER. I wonder if I should change that
instead. Kumar, what do you reckon ?
_Maybe_ an option is to have _PAGE_NO_USER that defaults to be
~_PAGE_USER in pte-common.h and can be set in pte-book3e.h to
only strip out UR and UW ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Only print clockevent settings once
From: Wolfram Sang @ 2010-02-08 4:53 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20100207222801.GE32246@kryten>
[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]
On Mon, Feb 08, 2010 at 09:28:01AM +1100, Anton Blanchard wrote:
>
> The clockevent multiplier and shift is useful information, but we
> only need to print it once.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
>
> Index: powerpc.git/arch/powerpc/kernel/time.c
> ===================================================================
> --- powerpc.git.orig/arch/powerpc/kernel/time.c 2010-02-05 14:57:48.839716602 +1100
> +++ powerpc.git/arch/powerpc/kernel/time.c 2010-02-05 14:57:53.057212067 +1100
> @@ -930,13 +930,17 @@ static void __init setup_clockevent_mult
>
> static void register_decrementer_clockevent(int cpu)
> {
> + static int printed = 0;
> struct clock_event_device *dec = &per_cpu(decrementers, cpu).event;
>
> *dec = decrementer_clockevent;
> dec->cpumask = cpumask_of(cpu);
>
> - printk(KERN_DEBUG "clockevent: %s mult[%x] shift[%d] cpu[%d]\n",
> - dec->name, dec->mult, dec->shift, cpu);
> + if (!printed) {
> + printed = 1;
> + printk(KERN_DEBUG "clockevent: %s mult[%x] shift[%d] cpu[%d]\n",
> + dec->name, dec->mult, dec->shift, cpu);
> + }
What about printk_once from kernel.h?
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Restrict stack space reservation to rlimit
From: Anton Blanchard @ 2010-02-08 5:11 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Michael Neuling, stable, aeb, James Morris, miltonm,
Oleg Nesterov, linuxppc-dev, Paul Mackerras, Alexander Viro,
WANG Cong, linux-fsdevel, Serge Hallyn, Andrew Morton,
Linus Torvalds, Ingo Molnar, linux-kernel
In-Reply-To: <20100208140323.FB52.A69D9226@jp.fujitsu.com>
Hi,
> Why do we need page size independent stack size? It seems to have
> compatibility breaking risk.
I don't think so. The current behaviour is clearly wrong, we dont need a
16x larger stack just because you went from a 4kB to a 64kB base page
size. The user application stack usage is the same in both cases.
Anton
^ permalink raw reply
* Re: [PATCH] Restrict stack space reservation to rlimit
From: KOSAKI Motohiro @ 2010-02-08 5:22 UTC (permalink / raw)
To: Anton Blanchard
Cc: Michael Neuling, stable, aeb, Oleg Nesterov, miltonm,
James Morris, linuxppc-dev, Paul Mackerras, Alexander Viro,
kosaki.motohiro, WANG Cong, linux-fsdevel, Serge Hallyn,
Andrew Morton, Linus Torvalds, Ingo Molnar, linux-kernel
In-Reply-To: <20100208051104.GL32246@kryten>
>
> Hi,
>
> > Why do we need page size independent stack size? It seems to have
> > compatibility breaking risk.
>
> I don't think so. The current behaviour is clearly wrong, we dont need a
> 16x larger stack just because you went from a 4kB to a 64kB base page
> size. The user application stack usage is the same in both cases.
I didn't discuss which behavior is better. Michael said he want to apply
his patch to 2.6.32 & 2.6.33. stable tree never accept the breaking
compatibility patch.
Your answer doesn't explain why can't we wait it until next merge window.
btw, personally, I like page size indepent stack size. but I'm not sure
why making stack size independency is related to bug fix.
^ permalink raw reply
* Re: [PATCH] powerpc: Only print clockevent settings once
From: Anton Blanchard @ 2010-02-08 5:26 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20100208045319.GA1405@pengutronix.de>
Hi Wolfram,
> What about printk_once from kernel.h?
Thanks for the suggestion!
Anton
--
The clockevent multiplier and shift is useful information, but we
only need to print it once.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/time.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/time.c 2010-02-08 11:45:12.933073040 +1100
+++ powerpc.git/arch/powerpc/kernel/time.c 2010-02-08 16:21:08.505571532 +1100
@@ -935,8 +935,8 @@ static void register_decrementer_clockev
*dec = decrementer_clockevent;
dec->cpumask = cpumask_of(cpu);
- printk(KERN_DEBUG "clockevent: %s mult[%x] shift[%d] cpu[%d]\n",
- dec->name, dec->mult, dec->shift, cpu);
+ printk_once(KERN_DEBUG "clockevent: %s mult[%x] shift[%d] cpu[%d]\n",
+ dec->name, dec->mult, dec->shift, cpu);
clockevents_register_device(dec);
}
^ permalink raw reply
* Re: [PATCH] Restrict stack space reservation to rlimit
From: Anton Blanchard @ 2010-02-08 5:31 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Michael Neuling, stable, aeb, James Morris, miltonm,
Oleg Nesterov, linuxppc-dev, Paul Mackerras, Alexander Viro,
WANG Cong, linux-fsdevel, Serge Hallyn, Andrew Morton,
Linus Torvalds, Ingo Molnar, linux-kernel
In-Reply-To: <20100208141716.FB55.A69D9226@jp.fujitsu.com>
Hi,
> I didn't discuss which behavior is better. Michael said he want to apply
> his patch to 2.6.32 & 2.6.33. stable tree never accept the breaking
> compatibility patch.
>
> Your answer doesn't explain why can't we wait it until next merge window.
>
>
> btw, personally, I like page size indepent stack size. but I'm not sure
> why making stack size independency is related to bug fix.
OK sorry, I misunderstood your initial mail. I agree fixing the bit that
regressed in 2.6.32 is the most important thing. The difference in page size is
clearly wrong but since it isn't a regression we could probably live with it
until 2.6.34
Anton
^ permalink raw reply
* Re: [PATCH] Restrict stack space reservation to rlimit
From: KOSAKI Motohiro @ 2010-02-08 5:06 UTC (permalink / raw)
To: Michael Neuling
Cc: stable, aeb, James Morris, miltonm, Oleg Nesterov, linuxppc-dev,
Paul Mackerras, Alexander Viro, kosaki.motohiro, WANG Cong,
linux-fsdevel, Serge Hallyn, Andrew Morton, Linus Torvalds,
Ingo Molnar, linux-kernel, Anton Blanchard
In-Reply-To: <18033.1265587672@neuling.org>
Hi
> apkm, linus: this or something like it needs to go into 2.6.33 (& 32) to
> fix 'ulimit -s'.
"fix ulimit -s" is too cool explanation ;-)
we are not ESPer. please consider to provide what bug is exist.
> Mikey
>
> [PATCH] Restrict stack space reservation to rlimit
>
> When reserving stack space for a new process, make sure we're not
> attempting to allocate more than rlimit allows.
>
> Also, reserve the same stack size independent of page size.
Why do we need page size independent stack size? It seems to have
compatibility breaking risk.
>
> This fixes a bug unmasked by fc63cf237078c86214abcb2ee9926d8ad289da9b
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> Cc: Anton Blanchard <anton@samba.org>
> Cc: stable@kernel.org
> ---
> fs/exec.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> Index: clone1/fs/exec.c
> ===================================================================
> --- clone1.orig/fs/exec.c
> +++ clone1/fs/exec.c
> @@ -554,7 +554,7 @@ static int shift_arg_pages(struct vm_are
> return 0;
> }
>
> -#define EXTRA_STACK_VM_PAGES 20 /* random */
> +#define EXTRA_STACK_VM_SIZE 81920UL /* randomly 20 4K pages */
>
> /*
> * Finalizes the stack vm_area_struct. The flags and permissions are updated,
> @@ -627,10 +627,13 @@ int setup_arg_pages(struct linux_binprm
> goto out_unlock;
> }
>
> + stack_base = min(EXTRA_STACK_VM_SIZE,
> + current->signal->rlim[RLIMIT_STACK].rlim_cur) -
> + PAGE_SIZE;
> #ifdef CONFIG_STACK_GROWSUP
> - stack_base = vma->vm_end + EXTRA_STACK_VM_PAGES * PAGE_SIZE;
> + stack_base = vma->vm_end + stack_base;
> #else
> - stack_base = vma->vm_start - EXTRA_STACK_VM_PAGES * PAGE_SIZE;
> + stack_base = vma->vm_start - stack_base;
> #endif
> ret = expand_stack(vma, stack_base);
> if (ret)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Clear MSR_RI during RTAS calls
From: Anton Blanchard @ 2010-02-08 5:37 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
RTAS should never cause an exception but if it does (for example accessing
outside our RMO) then we might go a long way through the kernel before
oopsing. If we unset MSR_RI we should at least stop things on exception
exit.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
The setting of MSR_RI during RTAS calls went in ages ago (2003), and I'm
not sure why. Clearly an exception inside RTAS is fatal since we most likely
have a bad r13.
Index: powerpc.git/arch/powerpc/kernel/entry_64.S
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/entry_64.S 2010-02-08 12:25:51.543072119 +1100
+++ powerpc.git/arch/powerpc/kernel/entry_64.S 2010-02-08 12:26:56.043513290 +1100
@@ -791,9 +791,8 @@ _GLOBAL(enter_rtas)
li r9,1
rldicr r9,r9,MSR_SF_LG,(63-MSR_SF_LG)
- ori r9,r9,MSR_IR|MSR_DR|MSR_FE0|MSR_FE1|MSR_FP
+ ori r9,r9,MSR_IR|MSR_DR|MSR_FE0|MSR_FE1|MSR_FP|MSR_RI
andc r6,r0,r9
- ori r6,r6,MSR_RI
sync /* disable interrupts so SRR0/1 */
mtmsrd r0 /* don't get trashed */
^ permalink raw reply
* [PATCH] Restrict stack space reservation to rlimit
From: Michael Neuling @ 2010-02-08 5:37 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: stable, aeb, James Morris, miltonm, Oleg Nesterov, linuxppc-dev,
Paul Mackerras, Anton Blanchard, WANG Cong, linux-fsdevel,
Serge Hallyn, Andrew Morton, Linus Torvalds, Ingo Molnar,
linux-kernel, Alexander Viro
In-Reply-To: <20100208141716.FB55.A69D9226@jp.fujitsu.com>
> >
> > Hi,
> >
> > > Why do we need page size independent stack size? It seems to have
> > > compatibility breaking risk.
> >
> > I don't think so. The current behaviour is clearly wrong, we dont need a
> > 16x larger stack just because you went from a 4kB to a 64kB base page
> > size. The user application stack usage is the same in both cases.
>
> I didn't discuss which behavior is better. Michael said he want to apply
> his patch to 2.6.32 & 2.6.33. stable tree never accept the breaking
> compatibility patch.
>
> Your answer doesn't explain why can't we wait it until next merge window.
>
> btw, personally, I like page size indepent stack size. but I'm not sure
> why making stack size independency is related to bug fix.
I tend to agree.
Below is just the bug fix to limit the reservation size based rlimit.
We still reserve different stack sizes based on the page size as
before (unless we hit rlimit of course).
Mikey
Restrict stack space reservation to rlimit
When reserving stack space for a new process, make sure we're not
attempting to allocate more than rlimit allows.
This fixes a bug cause by b6a2fea39318e43fee84fa7b0b90d68bed92d2ba
"mm: variable length argument support" and unmasked by
fc63cf237078c86214abcb2ee9926d8ad289da9b
"exec: setup_arg_pages() fails to return errors".
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: stable@kernel.org
---
fs/exec.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/fs/exec.c
===================================================================
--- linux-2.6-ozlabs.orig/fs/exec.c
+++ linux-2.6-ozlabs/fs/exec.c
@@ -627,10 +627,13 @@ int setup_arg_pages(struct linux_binprm
goto out_unlock;
}
+ stack_base = min(EXTRA_STACK_VM_PAGES * PAGE_SIZE,
+ current->signal->rlim[RLIMIT_STACK].rlim_cur -
+ PAGE_SIZE);
#ifdef CONFIG_STACK_GROWSUP
- stack_base = vma->vm_end + EXTRA_STACK_VM_PAGES * PAGE_SIZE;
+ stack_base = vma->vm_end + stack_base;
#else
- stack_base = vma->vm_start - EXTRA_STACK_VM_PAGES * PAGE_SIZE;
+ stack_base = vma->vm_start - stack_base;
#endif
ret = expand_stack(vma, stack_base);
if (ret)
^ permalink raw reply
* Re: [PATCH] Clear MSR_RI during RTAS calls
From: Anton Blanchard @ 2010-02-08 5:43 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20100208053729.GO32246@kryten>
> The setting of MSR_RI during RTAS calls went in ages ago (2003), and I'm
> not sure why. Clearly an exception inside RTAS is fatal since we most likely
> have a bad r13.
I wrote the r13 comment without thinking :) Regardless I think we want
to catch any RTAS exception ASAP.
Anton
^ permalink raw reply
* Re: [PATCH] Restrict stack space reservation to rlimit
From: KOSAKI Motohiro @ 2010-02-08 6:05 UTC (permalink / raw)
To: Michael Neuling
Cc: stable, aeb, Oleg Nesterov, miltonm, James Morris, linuxppc-dev,
Paul Mackerras, Anton Blanchard, kosaki.motohiro, WANG Cong,
linux-fsdevel, Serge Hallyn, Andrew Morton, Linus Torvalds,
Ingo Molnar, linux-kernel, Alexander Viro
In-Reply-To: <9729.1265607469@neuling.org>
> > >
> > > Hi,
> > >
> > > > Why do we need page size independent stack size? It seems to have
> > > > compatibility breaking risk.
> > >
> > > I don't think so. The current behaviour is clearly wrong, we dont need a
> > > 16x larger stack just because you went from a 4kB to a 64kB base page
> > > size. The user application stack usage is the same in both cases.
> >
> > I didn't discuss which behavior is better. Michael said he want to apply
> > his patch to 2.6.32 & 2.6.33. stable tree never accept the breaking
> > compatibility patch.
> >
> > Your answer doesn't explain why can't we wait it until next merge window.
> >
> > btw, personally, I like page size indepent stack size. but I'm not sure
> > why making stack size independency is related to bug fix.
>
> I tend to agree.
>
> Below is just the bug fix to limit the reservation size based rlimit.
> We still reserve different stack sizes based on the page size as
> before (unless we hit rlimit of course).
Thanks.
I agree your patch in almost part. but I have very few requests.
> Mikey
>
> Restrict stack space reservation to rlimit
>
> When reserving stack space for a new process, make sure we're not
> attempting to allocate more than rlimit allows.
>
> This fixes a bug cause by b6a2fea39318e43fee84fa7b0b90d68bed92d2ba
> "mm: variable length argument support" and unmasked by
> fc63cf237078c86214abcb2ee9926d8ad289da9b
> "exec: setup_arg_pages() fails to return errors".
Your initial mail have following problem use-case. please append it
into the patch description.
On recent ppc64 kernels, limiting the stack (using 'ulimit -s blah') is
now more restrictive than it was before. On 2.6.31 with 4k pages I
could run 'ulimit -s 16; /usr/bin/test' without a problem. Now with
mainline, even 'ulimit -s 64; /usr/bin/test' gets killed.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> Cc: Anton Blanchard <anton@samba.org>
> Cc: stable@kernel.org
> ---
> fs/exec.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> Index: linux-2.6-ozlabs/fs/exec.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/fs/exec.c
> +++ linux-2.6-ozlabs/fs/exec.c
> @@ -627,10 +627,13 @@ int setup_arg_pages(struct linux_binprm
> goto out_unlock;
> }
>
> + stack_base = min(EXTRA_STACK_VM_PAGES * PAGE_SIZE,
> + current->signal->rlim[RLIMIT_STACK].rlim_cur -
> + PAGE_SIZE);
This line is a bit unclear why "- PAGE_SIZE" is necessary.
personally, I like following likes explicit comments.
stack_expand = EXTRA_STACK_VM_PAGES * PAGE_SIZE;
stack_lim = ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur);
/* Initial stack must not cause stack overflow. */
if (stack_expand + PAGE_SIZE > stack_lim)
stack_expand = stack_lim - PAGE_SIZE;
note: accessing rlim_cur require ACCESS_ONCE.
Thought?
> #ifdef CONFIG_STACK_GROWSUP
> - stack_base = vma->vm_end + EXTRA_STACK_VM_PAGES * PAGE_SIZE;
> + stack_base = vma->vm_end + stack_base;
> #else
> - stack_base = vma->vm_start - EXTRA_STACK_VM_PAGES * PAGE_SIZE;
> + stack_base = vma->vm_start - stack_base;
> #endif
> ret = expand_stack(vma, stack_base);
> if (ret)
>
^ permalink raw reply
* Re: [PATCH] Restrict stack space reservation to rlimit
From: KOSAKI Motohiro @ 2010-02-08 6:11 UTC (permalink / raw)
To: Anton Blanchard
Cc: Michael Neuling, stable, aeb, Oleg Nesterov, miltonm,
James Morris, linuxppc-dev, Paul Mackerras, Alexander Viro,
kosaki.motohiro, WANG Cong, linux-fsdevel, Serge Hallyn,
Andrew Morton, Linus Torvalds, Ingo Molnar, linux-kernel
In-Reply-To: <20100208053125.GN32246@kryten>
>
> Hi,
>
> > I didn't discuss which behavior is better. Michael said he want to apply
> > his patch to 2.6.32 & 2.6.33. stable tree never accept the breaking
> > compatibility patch.
> >
> > Your answer doesn't explain why can't we wait it until next merge window.
> >
> >
> > btw, personally, I like page size indepent stack size. but I'm not sure
> > why making stack size independency is related to bug fix.
>
> OK sorry, I misunderstood your initial mail. I agree fixing the bit that
> regressed in 2.6.32 is the most important thing. The difference in page size is
> clearly wrong but since it isn't a regression we could probably live with it
> until 2.6.34
thanks!
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2010-02-08 6:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, linuxppc-dev list, Linux Kernel list
Hi Linus !
Here's a small regression fix that should still make it into .33
Cheers,
Ben.
The following changes since commit 6339204ecc2aa2067a99595522de0403f0854bb8:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../viro/vfs-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Mark Nelson (1):
powerpc/pseries: Fix kexec regression caused by CPPR tracking
arch/powerpc/platforms/pseries/xics.c | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH] Restrict stack space reservation to rlimit
From: Américo Wang @ 2010-02-08 7:07 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Michael Neuling, stable, aeb, Oleg Nesterov, miltonm,
James Morris, linuxppc-dev, Paul Mackerras, Anton Blanchard,
linux-fsdevel, Serge Hallyn, Andrew Morton, Linus Torvalds,
Ingo Molnar, linux-kernel, Alexander Viro
In-Reply-To: <20100208145240.FB58.A69D9226@jp.fujitsu.com>
On Mon, Feb 8, 2010 at 2:05 PM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
>> --- linux-2.6-ozlabs.orig/fs/exec.c
>> +++ linux-2.6-ozlabs/fs/exec.c
>> @@ -627,10 +627,13 @@ int setup_arg_pages(struct linux_binprm
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 goto out_unlock;
>> =C2=A0 =C2=A0 =C2=A0 }
>>
>> + =C2=A0 =C2=A0 stack_base =3D min(EXTRA_STACK_VM_PAGES * PAGE_SIZE,
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0current->signal->rlim[RLIMIT_STACK].rlim_cur -
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0PAGE_SIZE);
>
> This line is a bit unclear why "- PAGE_SIZE" is necessary.
> personally, I like following likes explicit comments.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0stack_expand =3D EXTRA_STACK_VM_PAGES * PAGE_S=
IZE;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0stack_lim =3D ACCESS_ONCE(rlim[RLIMIT_STACK].r=
lim_cur);
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Initial stack must not cause stack overflow=
. */
> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (stack_expand + PAGE_SIZE > stack_lim)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0stack_expand =3D s=
tack_lim - PAGE_SIZE;
>
> note: accessing rlim_cur require ACCESS_ONCE.
>
>
> Thought?
It's better to use the helper function: rlimit().
^ permalink raw reply
* Re: [PATCH] Restrict stack space reservation to rlimit
From: KOSAKI Motohiro @ 2010-02-08 7:11 UTC (permalink / raw)
To: Americo Wang
Cc: Michael Neuling, stable, aeb, Oleg Nesterov, miltonm,
James Morris, linuxppc-dev, Paul Mackerras, Anton Blanchard,
kosaki.motohiro, linux-fsdevel, Serge Hallyn, Andrew Morton,
Linus Torvalds, Ingo Molnar, linux-kernel, Alexander Viro
In-Reply-To: <2375c9f91002072307h4af1ba6dw1b7a598582991dc4@mail.gmail.com>
> On Mon, Feb 8, 2010 at 2:05 PM, KOSAKI Motohiro
> <kosaki.motohiro@jp.fujitsu.com> wrote:
> >> --- linux-2.6-ozlabs.orig/fs/exec.c
> >> +++ linux-2.6-ozlabs/fs/exec.c
> >> @@ -627,10 +627,13 @@ int setup_arg_pages(struct linux_binprm
> >> goto out_unlock;
> >> }
> >>
> >> + stack_base = min(EXTRA_STACK_VM_PAGES * PAGE_SIZE,
> >> + current->signal->rlim[RLIMIT_STACK].rlim_cur -
> >> + PAGE_SIZE);
> >
> > This line is a bit unclear why "- PAGE_SIZE" is necessary.
> > personally, I like following likes explicit comments.
> >
> > stack_expand = EXTRA_STACK_VM_PAGES * PAGE_SIZE;
> > stack_lim = ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur);
> >
> > /* Initial stack must not cause stack overflow. */
> > if (stack_expand + PAGE_SIZE > stack_lim)
> > stack_expand = stack_lim - PAGE_SIZE;
> >
> > note: accessing rlim_cur require ACCESS_ONCE.
> >
> >
> > Thought?
>
> It's better to use the helper function: rlimit().
AFAIK, stable tree doesn't have rlimit(). but yes, making two patch
(for mainline and for stable) is good opinion.
^ permalink raw reply
* Earliest Kernel to support FreeScale 8572
From: Igor @ 2010-02-08 9:16 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 310 bytes --]
What would be the earliest Kernel that has full support for 8572 (dual E500 core) ? Thanks in advance for any pointers.
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/
[-- Attachment #2: Type: text/html, Size: 492 bytes --]
^ permalink raw reply
* CPU usage spikes with MPC8377E IRQs
From: john.jarvis @ 2010-02-08 9:22 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I'm developing software for a custom MPC8377E-based board. I've run
into a strange problem that has me completely stumped and I would be
forever grateful for any suggestions or pointers.
I have a kernel module that basically handles IRQs produced every 1ms
and wakes up any processes that are blocked waiting. (The event is
saved in case a process has requested notification but is not waiting
at the moment the IRQ occurs.)
This works, except that every 28 seconds the IRQ thread, workqueue,
and user task all suddenly take up 100% CPU for 3 or 4 seconds.
(around 97% sys, then 97% IRQ, according to top) When this happens,
deadlines aren't met, watchdogs bark, motors crash, global warming
occurs...
Removing the workqueue and user task from the system simply isolates
an IRQ thread whose CPU usage spikes every 28 seconds. This has been
observed with both GTM and external IRQs. (I haven't tested others)
So, basically, for the GTM, the execution path is:
IRQ =3D> IPIC =3D> IRQ thread ACKs timer and returns IRQ_HANDLED =3D> IPIC =
=3D> IRQ
That's all. Spikes every 28 seconds.
System specs
------------------
CPU: MPC8377E (33.333Mhz timebase/133Mhz csb/400Mhz core)
Board: Custom
System controller: FPGA connected to the eLBC
Memory: DDR 1GB
ROM: NOR Flash connected to the FCM
RTC: None
Bootloader: U-Boot 1.3.3
Kernel: Linux 2.6.29-rt24
LTIB: mpc837xerdb-20081113=20
(w/custom configs. We started on an MPC8313ERDB)
Some notes:
* Spinlocks don't make a difference. (It's single-core anyway)
* Using a workqueue adds a thread to the workflow, but the spikes
still occur at the same frequency. (Actually, IRQ thread jumps
around 2s after workqueue)
* Changing the frequency of IRQs changes the time between spikes
between 1ms increments. 1ms, 2ms, 3ms are all the same. Fractions
are different.
* RT_PREEMPT kernel + real-time priority on user space task makes the
spikes shorter, but they still occur every 28 seconds.
* Kernel debug options seem to have no effect.
I have a version which sets up GTM1/Timer1 and ACKs event IRQs which I
can share if anyone is interested. It's a 3KB tgz. You'll have to modify th=
e=20
Makefile to fit your cross-compiler environment, and maybe edit the registe=
r=20
offset macros, too. But I think it's pretty generic code.
If there is a more approriate place to make this inquiry, please let me kno=
w.
(I think the traffic here is mostly kernel patches?)
Thank you,
John Jarvis =
^ permalink raw reply
* Re: [PATCH] Restrict stack space reservation to rlimit
From: Michael Neuling @ 2010-02-08 10:45 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: stable, aeb, James Morris, miltonm, Oleg Nesterov, linuxppc-dev,
Paul Mackerras, Anton Blanchard, WANG Cong, linux-fsdevel,
Serge Hallyn, Andrew Morton, Linus Torvalds, Ingo Molnar,
linux-kernel, Alexander Viro
In-Reply-To: <20100208145240.FB58.A69D9226@jp.fujitsu.com>
In message <20100208145240.FB58.A69D9226@jp.fujitsu.com> you wrote:
> > > >
> > > > Hi,
> > > >
> > > > > Why do we need page size independent stack size? It seems to have
> > > > > compatibility breaking risk.
> > > >
> > > > I don't think so. The current behaviour is clearly wrong, we dont need
a
> > > > 16x larger stack just because you went from a 4kB to a 64kB base page
> > > > size. The user application stack usage is the same in both cases.
> > >
> > > I didn't discuss which behavior is better. Michael said he want to apply
> > > his patch to 2.6.32 & 2.6.33. stable tree never accept the breaking
> > > compatibility patch.
> > >
> > > Your answer doesn't explain why can't we wait it until next merge window.
> > >
> > > btw, personally, I like page size indepent stack size. but I'm not sure
> > > why making stack size independency is related to bug fix.
> >
> > I tend to agree.
> >
> > Below is just the bug fix to limit the reservation size based rlimit.
> > We still reserve different stack sizes based on the page size as
> > before (unless we hit rlimit of course).
>
> Thanks.
>
> I agree your patch in almost part. but I have very few requests.
>
>
> > Mikey
> >
> > Restrict stack space reservation to rlimit
> >
> > When reserving stack space for a new process, make sure we're not
> > attempting to allocate more than rlimit allows.
> >
> > This fixes a bug cause by b6a2fea39318e43fee84fa7b0b90d68bed92d2ba
> > "mm: variable length argument support" and unmasked by
> > fc63cf237078c86214abcb2ee9926d8ad289da9b
> > "exec: setup_arg_pages() fails to return errors".
>
> Your initial mail have following problem use-case. please append it
> into the patch description.
>
> On recent ppc64 kernels, limiting the stack (using 'ulimit -s blah') is
> now more restrictive than it was before. On 2.6.31 with 4k pages I
> could run 'ulimit -s 16; /usr/bin/test' without a problem. Now with
> mainline, even 'ulimit -s 64; /usr/bin/test' gets killed.
Ok, I'll add this info in.
>
> >
> > Signed-off-by: Michael Neuling <mikey@neuling.org>
> > Cc: Anton Blanchard <anton@samba.org>
> > Cc: stable@kernel.org
> > ---
> > fs/exec.c | 7 +++++--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > Index: linux-2.6-ozlabs/fs/exec.c
> > ===================================================================
> > --- linux-2.6-ozlabs.orig/fs/exec.c
> > +++ linux-2.6-ozlabs/fs/exec.c
> > @@ -627,10 +627,13 @@ int setup_arg_pages(struct linux_binprm
> > goto out_unlock;
> > }
> >
> > + stack_base = min(EXTRA_STACK_VM_PAGES * PAGE_SIZE,
> > + current->signal->rlim[RLIMIT_STACK].rlim_cur -
> > + PAGE_SIZE);
>
> This line is a bit unclear why "- PAGE_SIZE" is necessary.
This is because the stack is already 1 page in size. I'm going to
change that code to make it clearer... hopefully :-)
> personally, I like following likes explicit comments.
>
> stack_expand = EXTRA_STACK_VM_PAGES * PAGE_SIZE;
> stack_lim = ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur);
>
> /* Initial stack must not cause stack overflow. */
> if (stack_expand + PAGE_SIZE > stack_lim)
> stack_expand = stack_lim - PAGE_SIZE;
>
> note: accessing rlim_cur require ACCESS_ONCE.
>
>
> Thought?
Thanks, looks better/clearer to me too. I'll change, new patch coming....
Mikey
>
>
> > #ifdef CONFIG_STACK_GROWSUP
> > - stack_base = vma->vm_end + EXTRA_STACK_VM_PAGES * PAGE_SIZE;
> > + stack_base = vma->vm_end + stack_base;
> > #else
> > - stack_base = vma->vm_start - EXTRA_STACK_VM_PAGES * PAGE_SIZE;
> > + stack_base = vma->vm_start - stack_base;
> > #endif
> > ret = expand_stack(vma, stack_base);
> > if (ret)
> >
>
>
>
^ permalink raw reply
* simpleImage.XX and large kernels
From: John Williams @ 2010-02-08 10:47 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm looking at the simpleImage.XXX make target (PPC 405/440), and it
seems that by default the arch/powerpc/boot/wrapper script places the
bootwrapper at 0x400000, effectively setting a limit on the maximum
bootable kernel size.
For various reasons we'd like to be able to put a fairly complete
rootfs as an initramfs, which obviously blows past a 4Mbyte limit very
quickly. Short of adding a new 'platform' option and associated
hackery through the powerpc/boot Makefiles and wrapper, is there a
quick and clean way I can tell the boot wrapper to link at a higher
address?
Thanks,
John
^ permalink raw reply
* Re: [PATCH] powerpc: Quieten cede latency printk
From: Balbir Singh @ 2010-02-08 11:07 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev, Gautham R Shenoy
In-Reply-To: <20100207235205.GI32246@kryten>
On Mon, Feb 8, 2010 at 5:22 AM, Anton Blanchard <anton@samba.org> wrote:
>
> The cede latency stuff is relatively new and we don't need to complain about
> it not working on older firmware.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Seems like a reasonable change. CC'ing Vaidy and Gautham to look even
more closely at the patch.
Balbir
^ 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