The flat loader uses an architecture's flat_stack_align() to align the
stack but assumes word-alignment is enough for the data sections.
However, on the Xtensa S6000 we have registers up to 128bit width
which can be used from userspace and therefor need userspace stack and
data-section alignment of at least this size.
This patch drops flat_stack_align() and uses the same alignment that
is required for slab caches, ARCH_SLAB_MINALIGN, or wordsize if it's
not defined by the architecture.
It also fixes m32r which was obviously kaput, aligning an
uninitialized stack entry instead of the stack pointer.
Signed-off-by: Oskar Schirmer <[email protected]>
Signed-off-by: Johannes Weiner <[email protected]>
Cc: David Howells <[email protected]>
Cc: Russell King <[email protected]>
Cc: Bryan Wu <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Paul Mundt <[email protected]>
Cc: Greg Ungerer <[email protected]>
Cc: Mike Frysinger <[email protected]>
---
arch/arm/include/asm/flat.h | 3 --
arch/blackfin/include/asm/flat.h | 1 -
arch/h8300/include/asm/flat.h | 1 -
arch/m68k/include/asm/flat.h | 1 -
arch/sh/include/asm/flat.h | 1 -
fs/binfmt_flat.c | 46 +++++++++++++++++++++++++------------
include/asm-m32r/flat.h | 1 -
7 files changed, 31 insertions(+), 23 deletions(-)
v3:
- checkpatch-clean (Andrew Morton)
- fixed the alignment space upon allocation calculation (Mike Frysinger)
- added a comment for the use of ARCH_SLAB_MINALIGN (Paul Mundt)
v2:
- replace local flat_data_align by ARCH_SLAB_MINALIGN (Paul Mundt)
diff --git a/arch/arm/include/asm/flat.h b/arch/arm/include/asm/flat.h
index 1d77e51..59426a4 100644
--- a/arch/arm/include/asm/flat.h
+++ b/arch/arm/include/asm/flat.h
@@ -5,9 +5,6 @@
#ifndef __ARM_FLAT_H__
#define __ARM_FLAT_H__
-/* An odd number of words will be pushed after this alignment, so
- deliberately misalign the value. */
-#define flat_stack_align(sp) sp = (void *)(((unsigned long)(sp) - 4) | 4)
#define flat_argvp_envp_on_stack() 1
#define flat_old_ram_flag(flags) (flags)
#define flat_reloc_valid(reloc, size) ((reloc) <= (size))
diff --git a/arch/blackfin/include/asm/flat.h b/arch/blackfin/include/asm/flat.h
index e70074e..733a178 100644
--- a/arch/blackfin/include/asm/flat.h
+++ b/arch/blackfin/include/asm/flat.h
@@ -10,7 +10,6 @@
#include <asm/unaligned.h>
-#define flat_stack_align(sp) /* nothing needed */
#define flat_argvp_envp_on_stack() 0
#define flat_old_ram_flag(flags) (flags)
diff --git a/arch/h8300/include/asm/flat.h b/arch/h8300/include/asm/flat.h
index 2a87350..bd12b31 100644
--- a/arch/h8300/include/asm/flat.h
+++ b/arch/h8300/include/asm/flat.h
@@ -5,7 +5,6 @@
#ifndef __H8300_FLAT_H__
#define __H8300_FLAT_H__
-#define flat_stack_align(sp) /* nothing needed */
#define flat_argvp_envp_on_stack() 1
#define flat_old_ram_flag(flags) 1
#define flat_reloc_valid(reloc, size) ((reloc) <= (size))
diff --git a/arch/m68k/include/asm/flat.h b/arch/m68k/include/asm/flat.h
index 814b517..a0e2907 100644
--- a/arch/m68k/include/asm/flat.h
+++ b/arch/m68k/include/asm/flat.h
@@ -5,7 +5,6 @@
#ifndef __M68KNOMMU_FLAT_H__
#define __M68KNOMMU_FLAT_H__
-#define flat_stack_align(sp) /* nothing needed */
#define flat_argvp_envp_on_stack() 1
#define flat_old_ram_flag(flags) (flags)
#define flat_reloc_valid(reloc, size) ((reloc) <= (size))
diff --git a/arch/sh/include/asm/flat.h b/arch/sh/include/asm/flat.h
index d3b2b4f..5d84df5 100644
--- a/arch/sh/include/asm/flat.h
+++ b/arch/sh/include/asm/flat.h
@@ -12,7 +12,6 @@
#ifndef __ASM_SH_FLAT_H
#define __ASM_SH_FLAT_H
-#define flat_stack_align(sp) /* nothing needed */
#define flat_argvp_envp_on_stack() 0
#define flat_old_ram_flag(flags) (flags)
#define flat_reloc_valid(reloc, size) ((reloc) <= (size))
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index 5cebf0b..697f6b5 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -41,6 +41,7 @@
#include <asm/uaccess.h>
#include <asm/unaligned.h>
#include <asm/cacheflush.h>
+#include <asm/page.h>
/****************************************************************************/
@@ -54,6 +55,18 @@
#define DBG_FLT(a...)
#endif
+/*
+ * User data (stack, data section and bss) needs to be aligned
+ * for the same reasons as SLAB memory is, and to the same amount.
+ * Avoid duplicating architecture specific code by using the same
+ * macro as with SLAB allocation:
+ */
+#ifdef ARCH_SLAB_MINALIGN
+#define FLAT_DATA_ALIGN (ARCH_SLAB_MINALIGN)
+#else
+#define FLAT_DATA_ALIGN (sizeof(void *))
+#endif
+
#define RELOC_FAILED 0xff00ff01 /* Relocation incorrect somewhere */
#define UNLOADED_LIB 0x7ff000ff /* Placeholder for unused library */
@@ -114,20 +127,18 @@ static unsigned long create_flat_tables(
int envc = bprm->envc;
char uninitialized_var(dummy);
- sp = (unsigned long *) ((-(unsigned long)sizeof(char *))&(unsigned long) p);
+ sp = (unsigned long *)p;
+ sp -= (envc + argc + 2) + 1 + (flat_argvp_envp_on_stack() ? 2 : 0);
+ sp = (unsigned long *) ((unsigned long)sp & -FLAT_DATA_ALIGN);
+ argv = sp + 1 + (flat_argvp_envp_on_stack() ? 2 : 0);
+ envp = argv + (argc + 1);
- sp -= envc+1;
- envp = sp;
- sp -= argc+1;
- argv = sp;
-
- flat_stack_align(sp);
if (flat_argvp_envp_on_stack()) {
- --sp; put_user((unsigned long) envp, sp);
- --sp; put_user((unsigned long) argv, sp);
+ put_user((unsigned long) envp, sp + 2);
+ put_user((unsigned long) argv, sp + 1);
}
- put_user(argc,--sp);
+ put_user(argc, sp);
current->mm->arg_start = (unsigned long) p;
while (argc-->0) {
put_user((unsigned long) p, argv++);
@@ -558,7 +569,9 @@ static int load_flat_file(struct linux_binprm * bprm,
ret = realdatastart;
goto err;
}
- datapos = realdatastart + MAX_SHARED_LIBS * sizeof(unsigned long);
+ datapos = ALIGN(realdatastart +
+ MAX_SHARED_LIBS * sizeof(unsigned long),
+ FLAT_DATA_ALIGN);
DBG_FLT("BINFMT_FLAT: Allocated data+bss+stack (%d bytes): %x\n",
(int)(data_len + bss_len + stack_len), (int)datapos);
@@ -604,9 +617,12 @@ static int load_flat_file(struct linux_binprm * bprm,
}
realdatastart = textpos + ntohl(hdr->data_start);
- datapos = realdatastart + MAX_SHARED_LIBS * sizeof(unsigned long);
- reloc = (unsigned long *) (textpos + ntohl(hdr->reloc_start) +
- MAX_SHARED_LIBS * sizeof(unsigned long));
+ datapos = ALIGN(realdatastart +
+ MAX_SHARED_LIBS * sizeof(unsigned long),
+ FLAT_DATA_ALIGN);
+
+ reloc = (unsigned long *)
+ (datapos + (ntohl(hdr->reloc_start) - text_len));
memp = textpos;
memp_size = len;
#ifdef CONFIG_BINFMT_ZFLAT
@@ -854,7 +870,7 @@ static int load_flat_binary(struct linux_binprm * bprm, struct pt_regs * regs)
stack_len = TOP_OF_ARGS - bprm->p; /* the strings */
stack_len += (bprm->argc + 1) * sizeof(char *); /* the argv array */
stack_len += (bprm->envc + 1) * sizeof(char *); /* the envp array */
-
+ stack_len += FLAT_DATA_ALIGN - 1; /* reserve for upcoming alignment */
res = load_flat_file(bprm, &libinfo, 0, &stack_len);
if (res > (unsigned long)-4096)
diff --git a/include/asm-m32r/flat.h b/include/asm-m32r/flat.h
index d851cf0..5d711c4 100644
--- a/include/asm-m32r/flat.h
+++ b/include/asm-m32r/flat.h
@@ -12,7 +12,6 @@
#ifndef __ASM_M32R_FLAT_H
#define __ASM_M32R_FLAT_H
-#define flat_stack_align(sp) (*sp += (*sp & 3 ? (4 - (*sp & 3)): 0))
#define flat_argvp_envp_on_stack() 0
#define flat_old_ram_flag(flags) (flags)
#define flat_set_persistent(relval, p) 0
On Thu, Mar 05, 2009 at 06:00:59PM +0100, Oskar Schirmer wrote:
> The flat loader uses an architecture's flat_stack_align() to align the
> stack but assumes word-alignment is enough for the data sections.
>
> However, on the Xtensa S6000 we have registers up to 128bit width
> which can be used from userspace and therefor need userspace stack and
> data-section alignment of at least this size.
>
> This patch drops flat_stack_align() and uses the same alignment that
> is required for slab caches, ARCH_SLAB_MINALIGN, or wordsize if it's
> not defined by the architecture.
>
> It also fixes m32r which was obviously kaput, aligning an
> uninitialized stack entry instead of the stack pointer.
>
> Signed-off-by: Oskar Schirmer <[email protected]>
> Signed-off-by: Johannes Weiner <[email protected]>
> Cc: David Howells <[email protected]>
> Cc: Russell King <[email protected]>
> Cc: Bryan Wu <[email protected]>
> Cc: Geert Uytterhoeven <[email protected]>
> Cc: Paul Mundt <[email protected]>
> Cc: Greg Ungerer <[email protected]>
> Cc: Mike Frysinger <[email protected]>
The updated version looks ok to me anyways, and it's certainly an
improvement over defining the same alignment requirements all over the
place.
Acked-by: Paul Mundt <[email protected]>
On Tue, 10 Mar 2009 16:33:50 +0900
Paul Mundt <[email protected]> wrote:
> On Thu, Mar 05, 2009 at 06:00:59PM +0100, Oskar Schirmer wrote:
> > The flat loader uses an architecture's flat_stack_align() to align the
> > stack but assumes word-alignment is enough for the data sections.
> >
> > However, on the Xtensa S6000 we have registers up to 128bit width
> > which can be used from userspace and therefor need userspace stack and
> > data-section alignment of at least this size.
> >
> > This patch drops flat_stack_align() and uses the same alignment that
> > is required for slab caches, ARCH_SLAB_MINALIGN, or wordsize if it's
> > not defined by the architecture.
> >
> > It also fixes m32r which was obviously kaput, aligning an
> > uninitialized stack entry instead of the stack pointer.
> >
> > Signed-off-by: Oskar Schirmer <[email protected]>
> > Signed-off-by: Johannes Weiner <[email protected]>
> > Cc: David Howells <[email protected]>
> > Cc: Russell King <[email protected]>
> > Cc: Bryan Wu <[email protected]>
> > Cc: Geert Uytterhoeven <[email protected]>
> > Cc: Paul Mundt <[email protected]>
> > Cc: Greg Ungerer <[email protected]>
> > Cc: Mike Frysinger <[email protected]>
>
> The updated version looks ok to me anyways, and it's certainly an
> improvement over defining the same alignment requirements all over the
> place.
>
> Acked-by: Paul Mundt <[email protected]>
Quite a few people expressed quite a few reservations over v2.
Are we all OK with a v3 merge?
From: Oskar Schirmer <[email protected]>
The flat loader uses an architecture's flat_stack_align() to align the
stack but assumes word-alignment is enough for the data sections.
However, on the Xtensa S6000 we have registers up to 128bit width
which can be used from userspace and therefor need userspace stack and
data-section alignment of at least this size.
This patch drops flat_stack_align() and uses the same alignment that
is required for slab caches, ARCH_SLAB_MINALIGN, or wordsize if it's
not defined by the architecture.
It also fixes m32r which was obviously kaput, aligning an
uninitialized stack entry instead of the stack pointer.
[[email protected]: coding-style fixes]
Signed-off-by: Oskar Schirmer <[email protected]>
Cc: David Howells <[email protected]>
Cc: Russell King <[email protected]>
Cc: Bryan Wu <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Acked-by: Paul Mundt <[email protected]>
Cc: Greg Ungerer <[email protected]>
Signed-off-by: Johannes Weiner <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
arch/arm/include/asm/flat.h | 3 -
arch/blackfin/include/asm/flat.h | 1
arch/h8300/include/asm/flat.h | 1
arch/m68k/include/asm/flat.h | 1
arch/sh/include/asm/flat.h | 1
fs/binfmt_flat.c | 46 +++++++++++++++++++----------
include/asm-m32r/flat.h | 1
7 files changed, 31 insertions(+), 23 deletions(-)
diff -puN arch/arm/include/asm/flat.h~flat-fix-data-sections-alignment arch/arm/include/asm/flat.h
--- a/arch/arm/include/asm/flat.h~flat-fix-data-sections-alignment
+++ a/arch/arm/include/asm/flat.h
@@ -5,9 +5,6 @@
#ifndef __ARM_FLAT_H__
#define __ARM_FLAT_H__
-/* An odd number of words will be pushed after this alignment, so
- deliberately misalign the value. */
-#define flat_stack_align(sp) sp = (void *)(((unsigned long)(sp) - 4) | 4)
#define flat_argvp_envp_on_stack() 1
#define flat_old_ram_flag(flags) (flags)
#define flat_reloc_valid(reloc, size) ((reloc) <= (size))
diff -puN arch/blackfin/include/asm/flat.h~flat-fix-data-sections-alignment arch/blackfin/include/asm/flat.h
--- a/arch/blackfin/include/asm/flat.h~flat-fix-data-sections-alignment
+++ a/arch/blackfin/include/asm/flat.h
@@ -10,7 +10,6 @@
#include <asm/unaligned.h>
-#define flat_stack_align(sp) /* nothing needed */
#define flat_argvp_envp_on_stack() 0
#define flat_old_ram_flag(flags) (flags)
diff -puN arch/h8300/include/asm/flat.h~flat-fix-data-sections-alignment arch/h8300/include/asm/flat.h
--- a/arch/h8300/include/asm/flat.h~flat-fix-data-sections-alignment
+++ a/arch/h8300/include/asm/flat.h
@@ -5,7 +5,6 @@
#ifndef __H8300_FLAT_H__
#define __H8300_FLAT_H__
-#define flat_stack_align(sp) /* nothing needed */
#define flat_argvp_envp_on_stack() 1
#define flat_old_ram_flag(flags) 1
#define flat_reloc_valid(reloc, size) ((reloc) <= (size))
diff -puN arch/m68k/include/asm/flat.h~flat-fix-data-sections-alignment arch/m68k/include/asm/flat.h
--- a/arch/m68k/include/asm/flat.h~flat-fix-data-sections-alignment
+++ a/arch/m68k/include/asm/flat.h
@@ -5,7 +5,6 @@
#ifndef __M68KNOMMU_FLAT_H__
#define __M68KNOMMU_FLAT_H__
-#define flat_stack_align(sp) /* nothing needed */
#define flat_argvp_envp_on_stack() 1
#define flat_old_ram_flag(flags) (flags)
#define flat_reloc_valid(reloc, size) ((reloc) <= (size))
diff -puN arch/sh/include/asm/flat.h~flat-fix-data-sections-alignment arch/sh/include/asm/flat.h
--- a/arch/sh/include/asm/flat.h~flat-fix-data-sections-alignment
+++ a/arch/sh/include/asm/flat.h
@@ -12,7 +12,6 @@
#ifndef __ASM_SH_FLAT_H
#define __ASM_SH_FLAT_H
-#define flat_stack_align(sp) /* nothing needed */
#define flat_argvp_envp_on_stack() 0
#define flat_old_ram_flag(flags) (flags)
#define flat_reloc_valid(reloc, size) ((reloc) <= (size))
diff -puN fs/binfmt_flat.c~flat-fix-data-sections-alignment fs/binfmt_flat.c
--- a/fs/binfmt_flat.c~flat-fix-data-sections-alignment
+++ a/fs/binfmt_flat.c
@@ -41,6 +41,7 @@
#include <asm/uaccess.h>
#include <asm/unaligned.h>
#include <asm/cacheflush.h>
+#include <asm/page.h>
/****************************************************************************/
@@ -54,6 +55,18 @@
#define DBG_FLT(a...)
#endif
+/*
+ * User data (stack, data section and bss) needs to be aligned
+ * for the same reasons as SLAB memory is, and to the same amount.
+ * Avoid duplicating architecture specific code by using the same
+ * macro as with SLAB allocation:
+ */
+#ifdef ARCH_SLAB_MINALIGN
+#define FLAT_DATA_ALIGN (ARCH_SLAB_MINALIGN)
+#else
+#define FLAT_DATA_ALIGN (sizeof(void *))
+#endif
+
#define RELOC_FAILED 0xff00ff01 /* Relocation incorrect somewhere */
#define UNLOADED_LIB 0x7ff000ff /* Placeholder for unused library */
@@ -114,20 +127,18 @@ static unsigned long create_flat_tables(
int envc = bprm->envc;
char uninitialized_var(dummy);
- sp = (unsigned long *) ((-(unsigned long)sizeof(char *))&(unsigned long) p);
+ sp = (unsigned long *)p;
+ sp -= (envc + argc + 2) + 1 + (flat_argvp_envp_on_stack() ? 2 : 0);
+ sp = (unsigned long *) ((unsigned long)sp & -FLAT_DATA_ALIGN);
+ argv = sp + 1 + (flat_argvp_envp_on_stack() ? 2 : 0);
+ envp = argv + (argc + 1);
- sp -= envc+1;
- envp = sp;
- sp -= argc+1;
- argv = sp;
-
- flat_stack_align(sp);
if (flat_argvp_envp_on_stack()) {
- --sp; put_user((unsigned long) envp, sp);
- --sp; put_user((unsigned long) argv, sp);
+ put_user((unsigned long) envp, sp + 2);
+ put_user((unsigned long) argv, sp + 1);
}
- put_user(argc,--sp);
+ put_user(argc, sp);
current->mm->arg_start = (unsigned long) p;
while (argc-->0) {
put_user((unsigned long) p, argv++);
@@ -558,7 +569,9 @@ static int load_flat_file(struct linux_b
ret = realdatastart;
goto err;
}
- datapos = realdatastart + MAX_SHARED_LIBS * sizeof(unsigned long);
+ datapos = ALIGN(realdatastart +
+ MAX_SHARED_LIBS * sizeof(unsigned long),
+ FLAT_DATA_ALIGN);
DBG_FLT("BINFMT_FLAT: Allocated data+bss+stack (%d bytes): %x\n",
(int)(data_len + bss_len + stack_len), (int)datapos);
@@ -604,9 +617,12 @@ static int load_flat_file(struct linux_b
}
realdatastart = textpos + ntohl(hdr->data_start);
- datapos = realdatastart + MAX_SHARED_LIBS * sizeof(unsigned long);
- reloc = (unsigned long *) (textpos + ntohl(hdr->reloc_start) +
- MAX_SHARED_LIBS * sizeof(unsigned long));
+ datapos = ALIGN(realdatastart +
+ MAX_SHARED_LIBS * sizeof(unsigned long),
+ FLAT_DATA_ALIGN);
+
+ reloc = (unsigned long *)
+ (datapos + (ntohl(hdr->reloc_start) - text_len));
memp = textpos;
memp_size = len;
#ifdef CONFIG_BINFMT_ZFLAT
@@ -854,7 +870,7 @@ static int load_flat_binary(struct linux
stack_len = TOP_OF_ARGS - bprm->p; /* the strings */
stack_len += (bprm->argc + 1) * sizeof(char *); /* the argv array */
stack_len += (bprm->envc + 1) * sizeof(char *); /* the envp array */
-
+ stack_len += FLAT_DATA_ALIGN - 1; /* reserve for upcoming alignment */
res = load_flat_file(bprm, &libinfo, 0, &stack_len);
if (res > (unsigned long)-4096)
diff -puN include/asm-m32r/flat.h~flat-fix-data-sections-alignment include/asm-m32r/flat.h
--- a/include/asm-m32r/flat.h~flat-fix-data-sections-alignment
+++ a/include/asm-m32r/flat.h
@@ -12,7 +12,6 @@
#ifndef __ASM_M32R_FLAT_H
#define __ASM_M32R_FLAT_H
-#define flat_stack_align(sp) (*sp += (*sp & 3 ? (4 - (*sp & 3)): 0))
#define flat_argvp_envp_on_stack() 0
#define flat_old_ram_flag(flags) (flags)
#define flat_set_persistent(relval, p) 0
_
On Thu, Apr 02, 2009 at 01:53:43PM -0700, Andrew Morton wrote:
> On Tue, 10 Mar 2009 16:33:50 +0900
> Paul Mundt <[email protected]> wrote:
>
> > On Thu, Mar 05, 2009 at 06:00:59PM +0100, Oskar Schirmer wrote:
> > > The flat loader uses an architecture's flat_stack_align() to align the
> > > stack but assumes word-alignment is enough for the data sections.
> > >
> > > However, on the Xtensa S6000 we have registers up to 128bit width
> > > which can be used from userspace and therefor need userspace stack and
> > > data-section alignment of at least this size.
> > >
> > > This patch drops flat_stack_align() and uses the same alignment that
> > > is required for slab caches, ARCH_SLAB_MINALIGN, or wordsize if it's
> > > not defined by the architecture.
> > >
> > > It also fixes m32r which was obviously kaput, aligning an
> > > uninitialized stack entry instead of the stack pointer.
> > >
> > > Signed-off-by: Oskar Schirmer <[email protected]>
> > > Signed-off-by: Johannes Weiner <[email protected]>
> > > Cc: David Howells <[email protected]>
> > > Cc: Russell King <[email protected]>
> > > Cc: Bryan Wu <[email protected]>
> > > Cc: Geert Uytterhoeven <[email protected]>
> > > Cc: Paul Mundt <[email protected]>
> > > Cc: Greg Ungerer <[email protected]>
> > > Cc: Mike Frysinger <[email protected]>
> >
> > The updated version looks ok to me anyways, and it's certainly an
> > improvement over defining the same alignment requirements all over the
> > place.
> >
> > Acked-by: Paul Mundt <[email protected]>
>
> Quite a few people expressed quite a few reservations over v2.
>
> Are we all OK with a v3 merge?
Paul and Mike had complaints. Paul acked the last revision. Mike?
We need this for upstream to compile on our configuration.
Hannes
Andrew Morton wrote:
> On Thu, 28 May 2009 09:08:02 +0900
> Paul Mundt <[email protected]> wrote:
>
>
>> On Wed, May 27, 2009 at 01:43:57PM -0700, Andrew Morton wrote:
>>
>>> On Wed, 27 May 2009 13:49:56 +0200
>>> Johannes Weiner <[email protected]> wrote:
>>>
>>>> On Tue, May 05, 2009 at 04:08:47PM +0200, Johannes Weiner wrote:
>>>>
>>>>> On Thu, Apr 09, 2009 at 04:25:53PM +0200, Johannes Weiner wrote:
>>>>>
>>>>>> On Thu, Apr 02, 2009 at 01:53:43PM -0700, Andrew Morton wrote:
>>>>>> Paul and Mike had complaints. Paul acked the last revision. Mike?
>>>>>> We need this for upstream to compile on our configuration.
>>>>>>
>>> Who is Mike?
>>>
>>> (A pox upon email clients which strip real names)
>>>
>>>
>>>>> Can we get this merged? Nobody complained.
>>>>>
>>>> <periodic echo-request>
>>>>
>>>> What are the plans on this now? I assume it drowned in other changes...
>>>> Is it too late to get this in .30 now?
>>>>
>>> The patch had a fairly shaky start and it's been unclear to me that
>>> everyone is happy with it and has tested it.
>>>
>>> arch/arm/include/asm/flat.h | 3 --
>>> arch/blackfin/include/asm/flat.h | 1
>>> arch/h8300/include/asm/flat.h | 1
>>> arch/m32r/include/asm/flat.h | 1
>>> arch/m68k/include/asm/flat.h | 1
>>> arch/sh/include/asm/flat.h | 1
>>> fs/binfmt_flat.c | 46 ++++++++++++++++++++++++++-------------
>>>
>>> I guess ARM is the major architecture amongst that lot. Have Russell
>>> and co had a decent look through this?
>>>
>>>
>> The problem here is that the ARM nommu people seem to have disappeared
>> shortly after getting their changes merged. I see no activity within the
>> kernel for ARM nommu since 2006.
>>
>
> heh, OK. Oskar touched it last, so he's now ARM nommu maintainer.
>
>
>> Given that xtensa has a need for this in
>> its nommu port and people are working on it presently, there certainly
>> has to be a limit to how far we go in allowing an outdated and
>> effectively abandoned port from blocking progress. Perhaps Russell has a
>> more optimistic outlook on the future of ARM nommu, though.
>>
>> The only architectures in that list presently active in the linux nommu
>> space in terms of development, support, and shipping products, are
>> blackfin, m68k, and sh. This too has been the case for years. Microblaze
>> has recently been added (which will also need the same change to its
>> flat.h), and it seems the xtensa folks are at least presently willing to
>> do more than the bare minimum to keep their port limping along.
>>
>
> OK, thanks, I'll send it in to Linus this week.
>
Can you remove flat_stack_align for Microblaze too? It should be in this
patch too.
Thanks,
Michal
diff --git a/arch/microblaze/include/asm/flat.h
b/arch/microblaze/include/asm/flat.h
index acf0da5..6847c15 100644
--- a/arch/microblaze/include/asm/flat.h
+++ b/arch/microblaze/include/asm/flat.h
@@ -13,7 +13,6 @@
#include <asm/unaligned.h>
-#define flat_stack_align(sp) /* nothing needed */
#define flat_argvp_envp_on_stack() 0
#define flat_old_ram_flag(flags) (flags)
#define flat_reloc_valid(reloc, size) ((reloc) <= (size))
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: http://www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
On Wed, May 27, 2009 at 17:16:31 -0700, Andrew Morton wrote:
> On Thu, 28 May 2009 09:08:02 +0900
> Paul Mundt <[email protected]> wrote:
>
> > On Wed, May 27, 2009 at 01:43:57PM -0700, Andrew Morton wrote:
> > > On Wed, 27 May 2009 13:49:56 +0200
> > > Johannes Weiner <[email protected]> wrote:
> > > > On Tue, May 05, 2009 at 04:08:47PM +0200, Johannes Weiner wrote:
> > > > > On Thu, Apr 09, 2009 at 04:25:53PM +0200, Johannes Weiner wrote:
> > > > > > On Thu, Apr 02, 2009 at 01:53:43PM -0700, Andrew Morton wrote:
> > > > > > Paul and Mike had complaints. Paul acked the last revision. Mike?
> > > > > > We need this for upstream to compile on our configuration.
> > >
> > > Who is Mike?
> > >
> > > (A pox upon email clients which strip real names)
> > >
> > > > > Can we get this merged? Nobody complained.
> > > >
> > > > <periodic echo-request>
> > > >
> > > > What are the plans on this now? I assume it drowned in other changes...
> > > > Is it too late to get this in .30 now?
> > >
> > > The patch had a fairly shaky start and it's been unclear to me that
> > > everyone is happy with it and has tested it.
> > >
> > > arch/arm/include/asm/flat.h | 3 --
> > > arch/blackfin/include/asm/flat.h | 1
> > > arch/h8300/include/asm/flat.h | 1
> > > arch/m32r/include/asm/flat.h | 1
> > > arch/m68k/include/asm/flat.h | 1
> > > arch/sh/include/asm/flat.h | 1
> > > fs/binfmt_flat.c | 46 ++++++++++++++++++++++++++-------------
> > >
> > > I guess ARM is the major architecture amongst that lot. Have Russell
> > > and co had a decent look through this?
> > >
> > The problem here is that the ARM nommu people seem to have disappeared
> > shortly after getting their changes merged. I see no activity within the
> > kernel for ARM nommu since 2006.
>
> heh, OK. Oskar touched it last, so he's now ARM nommu maintainer.
Well, I'ld need some test device for that purpose.
Someone around who can provide one?
Oskar
On Tue, Jun 2, 2009 at 10:15, Oskar Schirmer wrote:
> On Wed, May 27, 2009 at 17:16:31 -0700, Andrew Morton wrote:
>> On Thu, 28 May 2009 09:08:02 +0900
>> Paul Mundt <[email protected]> wrote:
>> > On Wed, May 27, 2009 at 01:43:57PM -0700, Andrew Morton wrote:
>> > > The patch had a fairly shaky start and it's been unclear to me that
>> > > everyone is happy with it and has tested it.
>> > >
>> > > arch/arm/include/asm/flat.h | 3 --
>> > > arch/blackfin/include/asm/flat.h | 1
>> > > arch/h8300/include/asm/flat.h | 1
>> > > arch/m32r/include/asm/flat.h | 1
>> > > arch/m68k/include/asm/flat.h | 1
>> > > arch/sh/include/asm/flat.h | 1
>> > > fs/binfmt_flat.c | 46 ++++++++++++++++++++++++++-------------
>> > >
>> > > I guess ARM is the major architecture amongst that lot. Have Russell
>> > > and co had a decent look through this?
>> > >
>> > The problem here is that the ARM nommu people seem to have disappeared
>> > shortly after getting their changes merged. I see no activity within the
>> > kernel for ARM nommu since 2006.
>>
>> heh, OK. Oskar touched it last, so he's now ARM nommu maintainer.
>
> Well, I'ld need some test device for that purpose.
> Someone around who can provide one?
seems a bit odd for a maintainer to not have any hardware ... at any
rate, dont you have an ARM system ? cant you just disable support for
the MMU ?
-mike
Hi Mike,
Mike Frysinger wrote:
> On Tue, Jun 2, 2009 at 10:15, Oskar Schirmer wrote:
>> On Wed, May 27, 2009 at 17:16:31 -0700, Andrew Morton wrote:
>>> On Thu, 28 May 2009 09:08:02 +0900
>>> Paul Mundt <[email protected]> wrote:
>>>> On Wed, May 27, 2009 at 01:43:57PM -0700, Andrew Morton wrote:
>>>>> The patch had a fairly shaky start and it's been unclear to me that
>>>>> everyone is happy with it and has tested it.
>>>>>
>>>>> arch/arm/include/asm/flat.h | 3 --
>>>>> arch/blackfin/include/asm/flat.h | 1
>>>>> arch/h8300/include/asm/flat.h | 1
>>>>> arch/m32r/include/asm/flat.h | 1
>>>>> arch/m68k/include/asm/flat.h | 1
>>>>> arch/sh/include/asm/flat.h | 1
>>>>> fs/binfmt_flat.c | 46 ++++++++++++++++++++++++++-------------
>>>>>
>>>>> I guess ARM is the major architecture amongst that lot. Have Russell
>>>>> and co had a decent look through this?
>>>>>
>>>> The problem here is that the ARM nommu people seem to have disappeared
>>>> shortly after getting their changes merged. I see no activity within the
>>>> kernel for ARM nommu since 2006.
>>> heh, OK. Oskar touched it last, so he's now ARM nommu maintainer.
>> Well, I'ld need some test device for that purpose.
>> Someone around who can provide one?
>
> seems a bit odd for a maintainer to not have any hardware ... at any
> rate, dont you have an ARM system ? cant you just disable support for
> the MMU ?
The nommu support for arm is not complete in mainline.
(And that is why CONFIG_MMU is not a settable option in arm yet).
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: [email protected]
SnapGear Group, McAfee PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com