[uClinux-dev] [PATCH 4/4] FRV: Fix linux/elf-fdpic.h
It seems I accidentally switched the guard on linux/elf-fdpic.h from #ifdef
__KERNEL__ to #ifndef __KERNEL__ when attempting to expand the guarded region
to cover the elf_fdpic_params struct when doing the UAPI split - with the
result that the struct became unavailable to kernel code.
Move incorrectly guarded bits back to the kernelspace header.
Whilst we're at it, the __KERNEL__ guards can be deleted as they're no longer
necessary.
Reported-by: Fengguang Wu fengguang...@intel.com
Reported-by: Lars-Peter Clausen l...@metafoo.de
Signed-off-by: David Howells dhowe...@redhat.com
cc: Fengguang Wu fengguang...@intel.com
cc: Lars-Peter Clausen l...@metafoo.de
cc: uclinux-dev@uclinux.org
---
include/uapi/linux/elf-fdpic.h | 42 +++-
1 file changed, 3 insertions(+), 39 deletions(-)
diff --git a/include/uapi/linux/elf-fdpic.h b/include/uapi/linux/elf-fdpic.h
index 1065078..3921e33 100644
--- a/include/uapi/linux/elf-fdpic.h
+++ b/include/uapi/linux/elf-fdpic.h
@@ -9,8 +9,8 @@
* 2 of the License, or (at your option) any later version.
*/
-#ifndef _LINUX_ELF_FDPIC_H
-#define _LINUX_ELF_FDPIC_H
+#ifndef _UAPI_LINUX_ELF_FDPIC_H
+#define _UAPI_LINUX_ELF_FDPIC_H
#include linux/elf.h
@@ -31,40 +31,4 @@ struct elf32_fdpic_loadmap {
#define ELF32_FDPIC_LOADMAP_VERSION0x
-#ifndef __KERNEL__
-/*
- * binfmt binary parameters structure
- */
-struct elf_fdpic_params {
- struct elfhdr hdr;/* ref copy of ELF
header */
- struct elf_phdr *phdrs; /* ref copy of PT_PHDR
table */
- struct elf32_fdpic_loadmap *loadmap; /* loadmap to be passed
to userspace */
- unsigned long elfhdr_addr;/* mapped ELF header
user address */
- unsigned long ph_addr;/* mapped PT_PHDR user
address */
- unsigned long map_addr; /* mapped loadmap user
address */
- unsigned long entry_addr; /* mapped entry user
address */
- unsigned long stack_size; /* stack size requested
(PT_GNU_STACK) */
- unsigned long dynamic_addr; /* mapped PT_DYNAMIC
user address */
- unsigned long load_addr; /* user address at
which to map binary */
- unsigned long flags;
-#define ELF_FDPIC_FLAG_ARRANGEMENT 0x000f /* PT_LOAD arrangement
flags */
-#define ELF_FDPIC_FLAG_INDEPENDENT 0x /* PT_LOADs can be put
anywhere */
-#define ELF_FDPIC_FLAG_HONOURVADDR 0x0001 /* PT_LOAD.vaddr must
be honoured */
-#define ELF_FDPIC_FLAG_CONSTDISP 0x0002 /* PT_LOADs require
constant
-* displacement */
-#define ELF_FDPIC_FLAG_CONTIGUOUS 0x0003 /* PT_LOADs should be
contiguous */
-#define ELF_FDPIC_FLAG_EXEC_STACK 0x0010 /* T if stack to be
executable */
-#define ELF_FDPIC_FLAG_NOEXEC_STACK0x0020 /* T if stack not to be
executable */
-#define ELF_FDPIC_FLAG_EXECUTABLE 0x0040 /* T if this object is
the executable */
-#define ELF_FDPIC_FLAG_PRESENT 0x8000 /* T if this object is
present */
-};
-
-#ifdef CONFIG_MMU
-extern void elf_fdpic_arch_lay_out_mm(struct elf_fdpic_params *exec_params,
- struct elf_fdpic_params *interp_params,
- unsigned long *start_stack,
- unsigned long *start_brk);
-#endif
-#endif /* __KERNEL__ */
-
-#endif /* _LINUX_ELF_FDPIC_H */
+#endif /* _UAPI_LINUX_ELF_FDPIC_H */
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH 4/4] FRV: Fix linux/elf-fdpic.h
Lars-Peter Clausen l...@metafoo.de wrote: The second part of the patch adding it back to include/linux/elf-fdpic.h seems to be missing. Oops. Yes. I forgot to 'stg add' it. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 4/4] FRV: Fix linux/elf-fdpic.h [ver #2]
It seems I accidentally switched the guard on linux/elf-fdpic.h from #ifdef
__KERNEL__ to #ifndef __KERNEL__ when attempting to expand the guarded region
to cover the elf_fdpic_params struct when doing the UAPI split - with the
result that the struct became unavailable to kernel code.
Move incorrectly guarded bits back to the kernelspace header.
Whilst we're at it, the __KERNEL__ guards can be deleted as they're no longer
necessary.
Reported-by: Fengguang Wu fengguang...@intel.com
Reported-by: Lars-Peter Clausen l...@metafoo.de
Signed-off-by: David Howells dhowe...@redhat.com
cc: Fengguang Wu fengguang...@intel.com
cc: Lars-Peter Clausen l...@metafoo.de
cc: uclinux-dev@uclinux.org
---
include/linux/elf-fdpic.h | 51
include/uapi/linux/elf-fdpic.h | 42 ++---
2 files changed, 54 insertions(+), 39 deletions(-)
create mode 100644 include/linux/elf-fdpic.h
diff --git a/include/linux/elf-fdpic.h b/include/linux/elf-fdpic.h
new file mode 100644
index 000..3864403
--- /dev/null
+++ b/include/linux/elf-fdpic.h
@@ -0,0 +1,51 @@
+/* FDPIC ELF load map
+ *
+ * Copyright (C) 2003 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowe...@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _LINUX_ELF_FDPIC_H
+#define _LINUX_ELF_FDPIC_H
+
+#include uapi/linux/elf-fdpic.h
+
+/*
+ * binfmt binary parameters structure
+ */
+struct elf_fdpic_params {
+ struct elfhdr hdr;/* ref copy of ELF
header */
+ struct elf_phdr *phdrs; /* ref copy of PT_PHDR
table */
+ struct elf32_fdpic_loadmap *loadmap; /* loadmap to be passed
to userspace */
+ unsigned long elfhdr_addr;/* mapped ELF header
user address */
+ unsigned long ph_addr;/* mapped PT_PHDR user
address */
+ unsigned long map_addr; /* mapped loadmap user
address */
+ unsigned long entry_addr; /* mapped entry user
address */
+ unsigned long stack_size; /* stack size requested
(PT_GNU_STACK) */
+ unsigned long dynamic_addr; /* mapped PT_DYNAMIC
user address */
+ unsigned long load_addr; /* user address at
which to map binary */
+ unsigned long flags;
+#define ELF_FDPIC_FLAG_ARRANGEMENT 0x000f /* PT_LOAD arrangement
flags */
+#define ELF_FDPIC_FLAG_INDEPENDENT 0x /* PT_LOADs can be put
anywhere */
+#define ELF_FDPIC_FLAG_HONOURVADDR 0x0001 /* PT_LOAD.vaddr must
be honoured */
+#define ELF_FDPIC_FLAG_CONSTDISP 0x0002 /* PT_LOADs require
constant
+* displacement */
+#define ELF_FDPIC_FLAG_CONTIGUOUS 0x0003 /* PT_LOADs should be
contiguous */
+#define ELF_FDPIC_FLAG_EXEC_STACK 0x0010 /* T if stack to be
executable */
+#define ELF_FDPIC_FLAG_NOEXEC_STACK0x0020 /* T if stack not to be
executable */
+#define ELF_FDPIC_FLAG_EXECUTABLE 0x0040 /* T if this object is
the executable */
+#define ELF_FDPIC_FLAG_PRESENT 0x8000 /* T if this object is
present */
+};
+
+#ifdef CONFIG_MMU
+extern void elf_fdpic_arch_lay_out_mm(struct elf_fdpic_params *exec_params,
+ struct elf_fdpic_params *interp_params,
+ unsigned long *start_stack,
+ unsigned long *start_brk);
+#endif
+
+#endif /* _LINUX_ELF_FDPIC_H */
diff --git a/include/uapi/linux/elf-fdpic.h b/include/uapi/linux/elf-fdpic.h
index 1065078..3921e33 100644
--- a/include/uapi/linux/elf-fdpic.h
+++ b/include/uapi/linux/elf-fdpic.h
@@ -9,8 +9,8 @@
* 2 of the License, or (at your option) any later version.
*/
-#ifndef _LINUX_ELF_FDPIC_H
-#define _LINUX_ELF_FDPIC_H
+#ifndef _UAPI_LINUX_ELF_FDPIC_H
+#define _UAPI_LINUX_ELF_FDPIC_H
#include linux/elf.h
@@ -31,40 +31,4 @@ struct elf32_fdpic_loadmap {
#define ELF32_FDPIC_LOADMAP_VERSION0x
-#ifndef __KERNEL__
-/*
- * binfmt binary parameters structure
- */
-struct elf_fdpic_params {
- struct elfhdr hdr;/* ref copy of ELF
header */
- struct elf_phdr *phdrs; /* ref copy of PT_PHDR
table */
- struct elf32_fdpic_loadmap *loadmap; /* loadmap to be passed
to userspace */
- unsigned long elfhdr_addr;/* mapped ELF header
user address */
- unsigned long ph_addr;/* mapped PT_PHDR user
address
Re: [uClinux-dev] Latest GCC toolchain for m68k
Luis Alves lja...@gmail.com wrote: I'm currently using the 'experimental' pre-built gcc toolchain from http://www.uclinux.org/pub/uClinux/arm-elf-tools/tools-20080626/m68k-uclinux-tools-20080626.sh to build my uClinux-dist. I've never found any issue with that package, so I didn't even bother to build my own toolchain. But now I'm wondering: Is there a newer/better pre-built toolchain, or sorces for building a more recent one. If you're running a fairly recent RPM-based system, try looking in: http://people.redhat.com/~dhowells/cross/ You can download a gcc-4.7 based cross-gcc SRPM and a recent cross-binutils SRPM from there that will provide you with compilers for nearly all Linux arches, including m68k. If you're running Fedora 16 or above, yum will find the built RPMs in the updates-testing repository. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH] CRED: Fix load_flat_shared_library() to initialise bprm correctly
James Morris jmor...@namei.org wrote: Do these questions need to be answered before applying that patch? Not really; they can be fixed (if they are problems) in a separate patch. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] CRED: Fix load_flat_shared_library() to initialise bprm correctly
Fix binfmt_flag's load_flat_shared_library() to initialise bprm correctly. Currently, prepare_binprm() is called with only .filename .file and .cred fields set in bprm, but the .cred_prepared and .per_clear fields at least need initialising. Should the struct also be removed from the stack and allocated from the kmalloc pool instead as it's a huge structure? Also, is shared library loading potentially recursive? Reported-by: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp Signed-off-by: David Howells dhowe...@redhat.com --- fs/binfmt_flat.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index 397d305..1bffbe0 100644 --- a/fs/binfmt_flat.c +++ b/fs/binfmt_flat.c @@ -820,6 +820,8 @@ static int load_flat_shared_library(int id, struct lib_info *libs) int res; char buf[16]; + memset(bprm, 0, sizeof(bprm)); + /* Create the file name */ sprintf(buf, /lib/lib%d.so, id); @@ -835,6 +837,12 @@ static int load_flat_shared_library(int id, struct lib_info *libs) if (!bprm.cred) goto out; + /* We don't really care about recalculating credentials at this point +* as we're past the point of no return and are dealing with shared +* libraries. +*/ + bprm.cred_prepared = 1; + res = prepare_binprm(bprm); if (!IS_ERR_VALUE(res)) ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [uclinux-dist-devel] [PATCH] NOMMU: support SMP dynamic percpu_alloc
Mike Frysinger vap...@gentoo.org wrote: but David seems to be afk for a while ? Yeah... I moved house and then we had to redecorate and stuff, and whilst all that was going on, my FRV board has been locked away in storage. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [uclinux-dist-devel] [PATCH] NOMMU: support SMP dynamic percpu_alloc
Mike Frysinger vap...@gentoo.org wrote: that was going on, my FRV board has been locked away in storage. i can send you a free Blackfin board :) I never say no to stuff - which is part of the reason my office is a mess - but I have my FRV board connected back up now. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH] NOMMU: support SMP dynamic percpu_alloc
Mike Frysinger vap...@gentoo.org wrote:
The percpu code requires more functions to be implemented in the mm core
which nommu currently does not provide. So add inline implementations
since these are largely meaningless on nommu systems.
Under what conditions are these required?
I've seen one percpu compilation bug that I've made a patch for (see
attached), but none of these. Is SMP required to trigger them?
David
---
From: David Howells dhowe...@redhat.com
Subject: [PATCH] NOMMU: percpu should use is_vmalloc_addr().
per_cpu_ptr_to_phys() uses VMALLOC_START and VMALLOC_END to determine if an
address is in the vmalloc() region or not. This is incorrect on NOMMU as
there is no real vmalloc() capability (vmalloc() is emulated by kmalloc()).
The correct way to do this is to use is_vmalloc_addr(). This encapsulates the
vmalloc() region test in MMU mode and just returns 0 in NOMMU mode.
On FRV in NOMMU mode, the percpu compilation fails without this patch:
mm/percpu.c: In function 'per_cpu_ptr_to_phys':
mm/percpu.c:1011: error: 'VMALLOC_START' undeclared (first use in this function)
mm/percpu.c:1011: error: (Each undeclared identifier is reported only once
mm/percpu.c:1011: error: for each function it appears in.)
mm/percpu.c:1012: error: 'VMALLOC_END' undeclared (first use in this function)
mm/percpu.c:1018: warning: control reaches end of non-void function
Signed-off-by: David Howells dhowe...@redhat.com
---
mm/percpu.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/mm/percpu.c b/mm/percpu.c
index 3f93001..55d4d11 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1008,8 +1008,7 @@ phys_addr_t per_cpu_ptr_to_phys(void *addr)
}
if (in_first_chunk) {
- if ((unsigned long)addr VMALLOC_START ||
- (unsigned long)addr = VMALLOC_END)
+ if (!is_vmalloc_addr(addr))
return __pa(addr);
else
return page_to_phys(vmalloc_to_page(addr));
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] NOMMU: Stub out vm_get_page_prot() if there's no MMU
Stub out vm_get_page_prot() if there's no MMU.
This was added by commit:
commit 804af2cf6e7af31d2e664b54e6579b531dbd
Author: Hugh Dickins h...@veritas.com
Date: Wed Jul 26 21:39:49 2006 +0100
Subject: [AGPGART] remove private page protection map
and is used in commit:
commit c07fbfd17e614a76b194f371c5331e21e6cffb54
Author: Daniel De Graaf dgde...@tycho.nsa.gov
Date: Tue Aug 10 18:02:45 2010 -0700
Subject: fbmem: VM_IO set, but not propagated
in the fbmem video driver, but the function doesn't exist on NOMMU, resulting
in an undefined symbol at link time.
Signed-off-by: David Howells dhowe...@redhat.com
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
include/linux/mm.h |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 831c693..e6b1210 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1363,7 +1363,15 @@ static inline unsigned long vma_pages(struct
vm_area_struct *vma)
return (vma-vm_end - vma-vm_start) PAGE_SHIFT;
}
+#ifdef CONFIG_MMU
pgprot_t vm_get_page_prot(unsigned long vm_flags);
+#else
+static inline pgprot_t vm_get_page_prot(unsigned long vm_flags)
+{
+ return __pgprot(0);
+}
+#endif
+
struct vm_area_struct *find_extend_vma(struct mm_struct *, unsigned long addr);
int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
unsigned long pfn, unsigned long size, pgprot_t);
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] NOMMU: Stub out vm_get_page_prot() if there's no MMU
Stub out vm_get_page_prot() if there's no MMU.
This was added by commit:
commit 804af2cf6e7af31d2e664b54e6579b531dbd
Author: Hugh Dickins h...@veritas.com
Date: Wed Jul 26 21:39:49 2006 +0100
Subject: [AGPGART] remove private page protection map
and is used in commit:
commit c07fbfd17e614a76b194f371c5331e21e6cffb54
Author: Daniel De Graaf dgde...@tycho.nsa.gov
Date: Tue Aug 10 18:02:45 2010 -0700
Subject: fbmem: VM_IO set, but not propagated
in the fbmem video driver, but the function doesn't exist on NOMMU, resulting
in an undefined symbol at link time.
Signed-off-by: David Howells dhowe...@redhat.com
---
include/linux/mm.h |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 709f672..6b258c5 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1357,7 +1357,15 @@ static inline unsigned long vma_pages(struct
vm_area_struct *vma)
return (vma-vm_end - vma-vm_start) PAGE_SHIFT;
}
+#ifdef CONFIG_MMU
pgprot_t vm_get_page_prot(unsigned long vm_flags);
+#else
+static inline pgprot_t vm_get_page_prot(unsigned long vm_flags)
+{
+ return __pgprot(0);
+}
+#endif
+
struct vm_area_struct *find_extend_vma(struct mm_struct *, unsigned long addr);
int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
unsigned long pfn, unsigned long size, pgprot_t);
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH] FLAT: fix unmap len in load error path
Mike Frysinger vap...@gentoo.org wrote: The data chunk is mmaped with 'len' which remains unchanged, so use that when unmapping in the error path rather than trying to recalculate (and incorrectly so) the value used originally. Signed-off-by: Mike Frysinger vap...@gentoo.org Acked-by: David Howells dhowe...@redhat.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH] : Avoid filename TASK_SIZE test in do_getname() when no MMU
Greg Ungerer g...@snapgear.com wrote: +#define TASK_SIZE(0xUL) You might want to use ULONG_MAX instead of coding the number directly. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH] : Avoid filename TASK_SIZE test in do_getname() when no MMU
Philippe De Muyter p...@macqel.be wrote: +#else +#define TASK_SIZE (0xUL) +#endif Because of do_getname() : len = TASK_SIZE - (unsigned long) filename; we should rather have #define TASK_SIZE (0x1ull) Do you guarantee that will work everywhere on a 32-bit system, though? Note that it also makes things slower as gcc has to start using 64-bit arithmetic where it could otherwise use 32-bit arithmetic. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH] : Avoid filename TASK_SIZE test in do_getname() when no MMU
Jamie Lokier ja...@shareable.org wrote: TASK_SIZE is the wrong kind of check on no-MMU: A better check is that the address is within the userspace mappable address range, whatever that is, which may start at some value and end at some other value, and may have holes. I don't really think a comprehensive address check is a good idea. It would take too long to scan the mmap list for each address passed in to a system call. Better just not to do the check, or limit it to some reasonable upper bound as we do now. For FRV, the lower limit can be as low as 1 and the upper limit (if doing XIP) 0x. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH] : Avoid filename TASK_SIZE test in do_getname() when no MMU
Geert Uytterhoeven ge...@linux-m68k.org wrote: Are these also problematic? None of these are problematic for NOMMU FRV because there I set: #define TASK_SIZE __UL(0xUL) I would set it lower, but the flash is right at the top end of the address space, and if I want to do XIP from it, this is required. It's a fairly meaningless constant in NOMMU anyway, so it's probably better just to set it to this. Actually, I should probably use ULONG_MAX instead. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Newbe NOMMU question.
Jamie Lokier ja...@shareable.org wrote: I think current kernels share automatically when there are multiple instances of a text segment (any read-only file mapping), no matter how they are stored. But I'm not sure about this. That is the case. If possible, R/O private file mappings will be shared, and may even be shared from a backing device, such as flash, to do XIP. Documentation/nommu-mmap.txt gives some more information. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH v2] NOMMU: implement vmap/vunmap with kmalloc
How about the attached patch instead? I'd rather not make vmap() generally
available in NOMMU mode since it can't be implemented in NOMMU mode. Yes,
vmap() can take a copy of the pages it is given, but you can't guarantee
that's the right thing to do. It's like a shared-writable mmap.
Instead, why not just override vmap() in firmware_class.c for the one instance
where we know we're happy with this behaviour?
David
---
From: David Howells dhowe...@redhat.com
Subject: [PATCH] NOMMU: Work around the lack of vmap()/vunmap() in
firmware_loading_store()
Work around the lack of vmap()/vunmap() in firmware_loading_store() when
operating in NOMMU mode. vmap() cannot be implemented as there's no virtual
mapping available.
Instead, in NOMMU mode, coalesce the data into one big buffer and store as the
address vmap() would've returned.
Signed-off-by: David Howells dhowe...@redhat.com
---
drivers/base/firmware_class.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 18518ba..e33c2cb 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -59,6 +59,33 @@ static struct builtin_fw *__start_builtin_fw;
static struct builtin_fw *__end_builtin_fw;
#endif
+/*
+ * NOMMU mode can't provide vmap() as there's no MMU to do the virtual mapping.
+ * Coalesce the data into a big buffer instead.
+ */
+#ifndef CONFIG_MMU
+static void *__pretend_vmap(struct page **pages, unsigned int count,
+ unsigned long flags, pgprot_t prot)
+{
+ unsigned int i;
+ void *new_map, *page_data;
+
+ new_map = kmalloc(count PAGE_SHIFT, GFP_KERNEL);
+ if (!new_map)
+ return NULL;
+
+ for (i = 0; i count; ++i) {
+ page_data = kmap(pages[i]);
+ memcpy(new_map + (i PAGE_SHIFT), page_data, PAGE_SIZE);
+ kunmap(page_data);
+ }
+
+ return new_map;
+}
+
+#define vmap(pg, c, f, pr) __pretend_vmap(pg, c, f, pr)
+#endif /* !CONFIG_MMU */
+
static void
fw_load_abort(struct firmware_priv *fw_priv)
{
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH v2] NOMMU: implement vmap/vunmap with kmalloc
Mike Frysinger vap...@gentoo.org wrote: how about putting this implementation into like vmap_nommu() and only rewriting vmap() to vmap_nommu() when we know it's safe ? such as this firmware case ? Well, I'd argue it's _not_ vmap(), so it doesn't really make sense to call it such. Perhaps some better name? Perhaps vcopy()? David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH v2] NOMMU: implement vmap/vunmap with kmalloc
David Howells dhowe...@redhat.com wrote: how about putting this implementation into like vmap_nommu() and only rewriting vmap() to vmap_nommu() when we know it's safe ? such as this firmware case ? Well, I'd argue it's _not_ vmap(), so it doesn't really make sense to call it such. Perhaps some better name? Perhaps vcopy()? How about vcoalesce()? David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH] nommu: implement vmap/vunmap with kmalloc
Seems a reasonable idea. It could be done more efficiently if vunmap() was given the page count given to vmap(). David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 1/4] FDPIC: Respect PT_GNU_STACK exec protection markings when creating NOMMU stack
From: Mike Frysinger vap...@gentoo.org The current code will load the stack size and protection markings, but then only use the markings in the MMU code path. The NOMMU code path always passes PROT_EXEC to the mmap() call. While this doesn't matter to most people whilst the code is running, it will cause a pointless icache flush when starting every FDPIC application. Typically this icache flush will be of a region on the order of 128KB in size, or may be the entire icache, depending on the facilities available on the CPU. In the case where the arch default behaviour seems to be desired (EXSTACK_DEFAULT), we probe VM_STACK_FLAGS for VM_EXEC to determine whether we should be setting PROT_EXEC or not. For arches that support an MPU (Memory Protection Unit - an MMU without the virtual mapping capability), setting PROT_EXEC or not will make an important difference. It should be noted that this change also affects the executability of the brk region, since ELF-FDPIC has that share with the stack. However, this is probably irrelevant as NOMMU programs aren't likely to use the brk region, preferring instead allocation via mmap(). Signed-off-by: Mike Frysinger vap...@gentoo.org Signed-off-by: David Howells dhowe...@redhat.com --- arch/blackfin/include/asm/page.h |5 + arch/frv/include/asm/page.h |2 -- fs/binfmt_elf_fdpic.c| 13 +++-- 3 files changed, 16 insertions(+), 4 deletions(-) diff --git a/arch/blackfin/include/asm/page.h b/arch/blackfin/include/asm/page.h index 944a07c..1d04e40 100644 --- a/arch/blackfin/include/asm/page.h +++ b/arch/blackfin/include/asm/page.h @@ -10,4 +10,9 @@ #include asm-generic/page.h #define MAP_NR(addr) (((unsigned long)(addr)-PAGE_OFFSET) PAGE_SHIFT) +#define VM_DATA_DEFAULT_FLAGS \ + (VM_READ | VM_WRITE | \ + ((current-personality READ_IMPLIES_EXEC) ? VM_EXEC : 0 ) | \ +VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) + #endif diff --git a/arch/frv/include/asm/page.h b/arch/frv/include/asm/page.h index 25c6a50..8c97068 100644 --- a/arch/frv/include/asm/page.h +++ b/arch/frv/include/asm/page.h @@ -63,12 +63,10 @@ extern unsigned long max_pfn; #define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) PAGE_SHIFT) -#ifdef CONFIG_MMU #define VM_DATA_DEFAULT_FLAGS \ (VM_READ | VM_WRITE | \ ((current-personality READ_IMPLIES_EXEC) ? VM_EXEC : 0 ) | \ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) -#endif #endif /* __ASSEMBLY__ */ diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c index 7dc8599..c57d9ce 100644 --- a/fs/binfmt_elf_fdpic.c +++ b/fs/binfmt_elf_fdpic.c @@ -171,6 +171,9 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, #ifdef ELF_FDPIC_PLAT_INIT unsigned long dynaddr; #endif +#ifndef CONFIG_MMU + unsigned long stack_prot; +#endif struct file *interpreter = NULL; /* to shut gcc up */ char *interpreter_name = NULL; int executable_stack; @@ -316,6 +319,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, * defunct, deceased, etc. after this point we have to exit via * error_kill */ set_personality(PER_LINUX_FDPIC); + if (elf_read_implies_exec(exec_params.hdr, executable_stack)) + current-personality |= READ_IMPLIES_EXEC; set_binfmt(elf_fdpic_format); current-mm-start_code = 0; @@ -377,9 +382,13 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, if (stack_size PAGE_SIZE * 2) stack_size = PAGE_SIZE * 2; + stack_prot = PROT_READ | PROT_WRITE; + if (executable_stack == EXSTACK_ENABLE_X || + (executable_stack == EXSTACK_DEFAULT VM_STACK_FLAGS VM_EXEC)) + stack_prot |= PROT_EXEC; + down_write(current-mm-mmap_sem); - current-mm-start_brk = do_mmap(NULL, 0, stack_size, -PROT_READ | PROT_WRITE | PROT_EXEC, + current-mm-start_brk = do_mmap(NULL, 0, stack_size, stack_prot, MAP_PRIVATE | MAP_ANONYMOUS | MAP_UNINITIALIZED | MAP_GROWSDOWN, 0); ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 2/4] NOMMU: Avoiding duplicate icache flushes of shared maps
From: Mike Frysinger vapier@gmail.com
When working with FDPIC, there are many shared mappings of read-only code
regions between applications (the C library, applet packages like busybox,
etc.), but the current do_mmap_pgoff() function will issue an icache flush
whenever a VMA is added to an MM instead of only doing it when the map is
initially created.
The flush can instead be done when a region is first mmapped PROT_EXEC. Note
that we may not rely on the first mapping of a region being executable - it's
possible for it to be PROT_READ only, so we have to remember whether we've
flushed the region or not, and then flush the entire region when a bit of it is
made executable.
However, this also affects the brk area. That will no longer be executable.
We can mprotect() it to PROT_EXEC on MPU-mode kernels, but for NOMMU mode
kernels, when it increases the brk allocation, making sys_brk() flush the extra
from the icache should suffice. The brk area probably isn't used by NOMMU
programs since the brk area can only use up the leavings from the stack
allocation, where the stack allocation is larger than requested.
Signed-off-by: David Howells dhowe...@redhat.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
include/linux/mm_types.h |2 ++
mm/nommu.c | 11 ---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 84a524a..84d020b 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -123,6 +123,8 @@ struct vm_region {
struct file *vm_file; /* the backing file or NULL */
atomic_tvm_usage; /* region usage count */
+ boolvm_icache_flushed : 1; /* true if the icache has been
flushed for
+ * this region */
};
/*
diff --git a/mm/nommu.c b/mm/nommu.c
index 6f9248f..a8d1752 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -432,6 +432,7 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)
/*
* Ok, looks good - let it rip.
*/
+ flush_icache_range(mm-brk, brk);
return mm-brk = brk;
}
@@ -1353,10 +1354,14 @@ unsigned long do_mmap_pgoff(struct file *file,
share:
add_vma_to_mm(current-mm, vma);
- up_write(nommu_region_sem);
+ /* we flush the region from the icache only when the first executable
+* mapping of it is made */
+ if (vma-vm_flags VM_EXEC !region-vm_icache_flushed) {
+ flush_icache_range(region-vm_start, region-vm_end);
+ region-vm_icache_flushed = true;
+ }
- if (prot PROT_EXEC)
- flush_icache_range(result, result + len);
+ up_write(nommu_region_sem);
kleave( = %lx, result);
return result;
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 4/4] elf_fdpic_core_dump(): fix build break in 2.6.33-rc1
From: Daisuke HATAYAMA d.hatay...@jp.fujitsu.com
Commit f6151dfea21496d43dbaba32cfcd9c9f404769bc causes ELF-FDPIC to break
during building, so this patch fixes it together with a correction for the
printk format.
Signed-off-by: Daisuke HATAYAMA d.hatay...@jp.fujitsu.com
Reviewed-by: Masami Hiramatsu mhira...@redhat.com
Acked-by: Paul Mundt let...@linux-sh.org
Signed-off-by: David Howells dhowe...@redhat.com
---
fs/binfmt_elf_fdpic.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index c57d9ce..384a19f 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -1809,8 +1809,8 @@ static int elf_fdpic_core_dump(struct coredump_params
*cprm)
if (cprm-file-f_pos != offset) {
/* Sanity check */
- printk(KERN_WARNING
- elf_core_dump: file-f_pos (%lld) != offset (%lld)\n,
+ printk(KERN_WARNING elf_fdpic_core_dump:
+ cprm-file-f_pos (%lld) != offset (%lld)\n,
cprm-file-f_pos, offset);
}
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 3/4] NOMMU: Use copy_*_user_page() in access_process_vm()
From: Jie Zhang jie.zh...@analog.com
The MMU code uses the copy_*_user_page() variants in access_process_vm()
rather than copy_*_user() as the former includes an icache flush. This is
important when doing things like setting software breakpoints with gdb.
So switch the NOMMU code over to do the same.
This patch makes the reasonable assumption that copy_from_user_page() won't
fail - which is probably fine, as we've checked the VMA from which we're
copying is usable, and the copy is not allowed to cross VMAs. The one case
where it might go wrong is if the VMA is a device rather than RAM, and that
device returns an error which - in which case rubbish will be returned rather
than EIO.
Signed-off-by: Jie Zhang jie.zh...@analog.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
Signed-off-by: David Howells dhowe...@redhat.com
Acked-by: David McCullough david_mccullo...@mcafee.com
Acked-by: Paul Mundt let...@linux-sh.org
Acked-by: Greg Ungerer g...@uclinux.org
---
mm/nommu.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index a8d1752..1777386 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1921,9 +1921,11 @@ int access_process_vm(struct task_struct *tsk, unsigned
long addr, void *buf, in
/* only read or write mappings where it is permitted */
if (write vma-vm_flags VM_MAYWRITE)
- len -= copy_to_user((void *) addr, buf, len);
+ copy_to_user_page(vma, NULL, addr,
+(void *) addr, buf, len);
else if (!write vma-vm_flags VM_MAYREAD)
- len -= copy_from_user(buf, (void *) addr, len);
+ copy_from_user_page(vma, NULL, addr,
+ buf, (void *) addr, len);
else
len = 0;
} else {
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 4/4] elf_fdpic_core_dump(): fix build break in 2.6.33-rc1
Linus Torvalds torva...@linux-foundation.org wrote: So a strong NAK to this patch. Okay, forget that one then. Can you take the others? David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 1/4] FDPIC: Respect PT_GNU_STACK exec protection markings when creating NOMMU stack
Andrew Morton a...@linux-foundation.org wrote: So these patches and the MN10300 ones didn't get merged. Presumably because they're a grabbag of fixes and non-fixes and kinda-fixes with no particular ordering or precedence and they arrived newly-minted several days after the release of -rc1. I could suggest that you go back and sort them into 2.6.33-appropriate fixes and 2.6.34-appropriate non-fixes. Or you could try to cook up a good-sounding reason why the whole lot needs to go into 2.6.33. If you believe that ;) I did send them, plus others, during the merge window (albeit near the end). I then sent this lot after filtering out the extensions that should probably wait for the next merge window. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH v2] NOMMU: add [stack] label to per-process maps output
Okay. I've adjusted the desciption of the patch a little (see attached).
David
---
From: Mike Frysinger vap...@gentoo.org
Subject: [PATCH] NOMMU: Add '[stack]' label to /proc/pid/maps output
Add support to the NOMMU /proc/pid/maps file to show which mapping is the stack
of the original thread after execve. This is largely based on the MMU code.
Subsidiary thread stacks are not indicated.
For FDPIC, we now get:
root:/ cat /proc/self/maps
02064000-02067ccc rw-p 0004d000 00:01 22 /bin/busybox
0206e000-0206f35c rw-p 6000 00:01 295/lib/ld-uClibc.so.0
025f-025f6f0c r-xs 00:01 295/lib/ld-uClibc.so.0
0268-026ba6b0 r-xs 00:01 297/lib/libc.so.0
0270-0274d384 r-xs 00:01 22 /bin/busybox
02816000-02817000 rw-p 00:00 0
02848000-0284c0d8 rw-p 00:00 0
0286-0288 rw-p 00:00 0 [stack]
The semi-downside here is that for FLAT, we get:
root:/ cat /proc/155/maps
029f-029f9000 rwxp 00:00 0 [stack]
The reason being that FLAT combines a whole lot of stuff into one map
(including the stack). But this isn't any worse than the current output (which
is nothing), so screw it.
Signed-off-by: Mike Frysinger vap...@gentoo.org
Signed-off-by: David Howells dhowe...@redhat.com
---
fs/proc/task_nommu.c | 20
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/fs/proc/task_nommu.c b/fs/proc/task_nommu.c
index 5d9fd64..11827c0 100644
--- a/fs/proc/task_nommu.c
+++ b/fs/proc/task_nommu.c
@@ -121,11 +121,20 @@ int task_statm(struct mm_struct *mm, int *shared, int
*text,
return size;
}
+static void pad_len_spaces(struct seq_file *m, int len)
+{
+ len = 25 + sizeof(void*) * 6 - len;
+ if (len 1)
+ len = 1;
+ seq_printf(m, %*c, len, ' ');
+}
+
/*
* display a single VMA to a sequenced file
*/
static int nommu_vma_show(struct seq_file *m, struct vm_area_struct *vma)
{
+ struct mm_struct *mm = vma-vm_mm;
unsigned long ino = 0;
struct file *file;
dev_t dev = 0;
@@ -154,11 +163,14 @@ static int nommu_vma_show(struct seq_file *m, struct
vm_area_struct *vma)
MAJOR(dev), MINOR(dev), ino, len);
if (file) {
- len = 25 + sizeof(void *) * 6 - len;
- if (len 1)
- len = 1;
- seq_printf(m, %*c, len, ' ');
+ pad_len_spaces(m, len);
seq_path(m, file-f_path, );
+ } else if (mm) {
+ if (vma-vm_start = mm-start_stack
+ vma-vm_end = mm-start_stack) {
+ pad_len_spaces(m, len);
+ seq_puts(m, [stack]);
+ }
}
seq_putc(m, '\n');
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 1/4] FDPIC: Respect PT_GNU_STACK exec protection markings when creating NOMMU stack
From: Mike Frysinger vap...@gentoo.org The current code will load the stack size and protection markings, but then only use the markings in the MMU code path. The NOMMU code path always passes PROT_EXEC to the mmap() call. While this doesn't matter to most people whilst the code is running, it will cause a pointless icache flush when starting every FDPIC application. Typically this icache flush will be of a region on the order of 128KB in size, or may be the entire icache, depending on the facilities available on the CPU. In the case where the arch default behaviour seems to be desired (EXSTACK_DEFAULT), we probe VM_STACK_FLAGS for VM_EXEC to determine whether we should be setting PROT_EXEC or not. For arches that support an MPU (Memory Protection Unit - an MMU without the virtual mapping capability), setting PROT_EXEC or not will make an important difference. It should be noted that this change also affects the executability of the brk region, since ELF-FDPIC has that share with the stack. However, this is probably irrelevant as NOMMU programs aren't likely to use the brk region, preferring instead allocation via mmap(). Signed-off-by: Mike Frysinger vap...@gentoo.org Signed-off-by: David Howells dhowe...@redhat.com --- arch/blackfin/include/asm/page.h |5 + arch/frv/include/asm/page.h |2 -- fs/binfmt_elf_fdpic.c| 13 +++-- 3 files changed, 16 insertions(+), 4 deletions(-) diff --git a/arch/blackfin/include/asm/page.h b/arch/blackfin/include/asm/page.h index 944a07c..1d04e40 100644 --- a/arch/blackfin/include/asm/page.h +++ b/arch/blackfin/include/asm/page.h @@ -10,4 +10,9 @@ #include asm-generic/page.h #define MAP_NR(addr) (((unsigned long)(addr)-PAGE_OFFSET) PAGE_SHIFT) +#define VM_DATA_DEFAULT_FLAGS \ + (VM_READ | VM_WRITE | \ + ((current-personality READ_IMPLIES_EXEC) ? VM_EXEC : 0 ) | \ +VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) + #endif diff --git a/arch/frv/include/asm/page.h b/arch/frv/include/asm/page.h index 25c6a50..8c97068 100644 --- a/arch/frv/include/asm/page.h +++ b/arch/frv/include/asm/page.h @@ -63,12 +63,10 @@ extern unsigned long max_pfn; #define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) PAGE_SHIFT) -#ifdef CONFIG_MMU #define VM_DATA_DEFAULT_FLAGS \ (VM_READ | VM_WRITE | \ ((current-personality READ_IMPLIES_EXEC) ? VM_EXEC : 0 ) | \ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) -#endif #endif /* __ASSEMBLY__ */ diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c index c25256a..2917ab1 100644 --- a/fs/binfmt_elf_fdpic.c +++ b/fs/binfmt_elf_fdpic.c @@ -171,6 +171,9 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, #ifdef ELF_FDPIC_PLAT_INIT unsigned long dynaddr; #endif +#ifndef CONFIG_MMU + unsigned long stack_prot; +#endif struct file *interpreter = NULL; /* to shut gcc up */ char *interpreter_name = NULL; int executable_stack; @@ -316,6 +319,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, * defunct, deceased, etc. after this point we have to exit via * error_kill */ set_personality(PER_LINUX_FDPIC); + if (elf_read_implies_exec(exec_params.hdr, executable_stack)) + current-personality |= READ_IMPLIES_EXEC; set_binfmt(elf_fdpic_format); current-mm-start_code = 0; @@ -377,9 +382,13 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, if (stack_size PAGE_SIZE * 2) stack_size = PAGE_SIZE * 2; + stack_prot = PROT_READ | PROT_WRITE; + if (executable_stack == EXSTACK_ENABLE_X || + (executable_stack == EXSTACK_DEFAULT VM_STACK_FLAGS VM_EXEC)) + stack_prot |= PROT_EXEC; + down_write(current-mm-mmap_sem); - current-mm-start_brk = do_mmap(NULL, 0, stack_size, -PROT_READ | PROT_WRITE | PROT_EXEC, + current-mm-start_brk = do_mmap(NULL, 0, stack_size, stack_prot, MAP_PRIVATE | MAP_ANONYMOUS | MAP_UNINITIALIZED | MAP_GROWSDOWN, 0); ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 2/4] NOMMU: Avoiding duplicate icache flushes of shared maps
From: Mike Frysinger vapier@gmail.com
When working with FDPIC, there are many shared mappings of read-only code
regions between applications (the C library, applet packages like busybox,
etc.), but the current do_mmap_pgoff() function will issue an icache flush
whenever a VMA is added to an MM instead of only doing it when the map is
initially created.
The flush can instead be done when a region is first mmapped PROT_EXEC. Note
that we may not rely on the first mapping of a region being executable - it's
possible for it to be PROT_READ only, so we have to remember whether we've
flushed the region or not, and then flush the entire region when a bit of it is
made executable.
However, this also affects the brk area. That will no longer be executable.
We can mprotect() it to PROT_EXEC on MPU-mode kernels, but for NOMMU mode
kernels, when it increases the brk allocation, making sys_brk() flush the extra
from the icache should suffice. The brk area probably isn't used by NOMMU
programs since the brk area can only use up the leavings from the stack
allocation, where the stack allocation is larger than requested.
Signed-off-by: David Howells dhowe...@redhat.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
include/linux/mm_types.h |2 ++
mm/nommu.c | 11 ---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 84a524a..84d020b 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -123,6 +123,8 @@ struct vm_region {
struct file *vm_file; /* the backing file or NULL */
atomic_tvm_usage; /* region usage count */
+ boolvm_icache_flushed : 1; /* true if the icache has been
flushed for
+ * this region */
};
/*
diff --git a/mm/nommu.c b/mm/nommu.c
index 8687973..db52886 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -432,6 +432,7 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)
/*
* Ok, looks good - let it rip.
*/
+ flush_icache_range(mm-brk, brk);
return mm-brk = brk;
}
@@ -1353,10 +1354,14 @@ unsigned long do_mmap_pgoff(struct file *file,
share:
add_vma_to_mm(current-mm, vma);
- up_write(nommu_region_sem);
+ /* we flush the region from the icache only when the first executable
+* mapping of it is made */
+ if (vma-vm_flags VM_EXEC !region-vm_icache_flushed) {
+ flush_icache_range(region-vm_start, region-vm_end);
+ region-vm_icache_flushed = true;
+ }
- if (prot PROT_EXEC)
- flush_icache_range(result, result + len);
+ up_write(nommu_region_sem);
kleave( = %lx, result);
return result;
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 4/4] elf_fdpic_core_dump(): fix build break in 2.6.33-rc1
From: Daisuke HATAYAMA d.hatay...@jp.fujitsu.com
Commit f6151dfea21496d43dbaba32cfcd9c9f404769bc causes ELF-FDPIC to break
during building, so this patch fixes it together with a correction for the
printk format.
Signed-off-by: Daisuke HATAYAMA d.hatay...@jp.fujitsu.com
Reviewed-by: Masami Hiramatsu mhira...@redhat.com
Acked-by: Paul Mundt let...@linux-sh.org
Signed-off-by: David Howells dhowe...@redhat.com
---
fs/binfmt_elf_fdpic.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 2917ab1..384a19f 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -1807,11 +1807,11 @@ static int elf_fdpic_core_dump(struct coredump_params
*cprm)
ELF_CORE_WRITE_EXTRA_DATA;
#endif
- if (file-f_pos != offset) {
+ if (cprm-file-f_pos != offset) {
/* Sanity check */
- printk(KERN_WARNING
- elf_core_dump: file-f_pos (%lld) != offset (%lld)\n,
- file-f_pos, offset);
+ printk(KERN_WARNING elf_fdpic_core_dump:
+ cprm-file-f_pos (%lld) != offset (%lld)\n,
+ cprm-file-f_pos, offset);
}
end_coredump:
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 3/4] NOMMU: Use copy_*_user_page() in access_process_vm()
From: Jie Zhang jie.zh...@analog.com
The MMU code uses the copy_*_user_page() variants in access_process_vm()
rather than copy_*_user() as the former includes an icache flush. This is
important when doing things like setting software breakpoints with gdb.
So switch the NOMMU code over to do the same.
This patch makes the reasonable assumption that copy_from_user_page() won't
fail - which is probably fine, as we've checked the VMA from which we're
copying is usable, and the copy is not allowed to cross VMAs. The one case
where it might go wrong is if the VMA is a device rather than RAM, and that
device returns an error which - in which case rubbish will be returned rather
than EIO.
Signed-off-by: Jie Zhang jie.zh...@analog.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
Signed-off-by: David Howells dhowe...@redhat.com
Acked-by: David McCullough david_mccullo...@mcafee.com
Acked-by: Paul Mundt let...@linux-sh.org
Acked-by: Greg Ungerer g...@uclinux.org
---
mm/nommu.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index db52886..1e1ecb2 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1896,9 +1896,11 @@ int access_process_vm(struct task_struct *tsk, unsigned
long addr, void *buf, in
/* only read or write mappings where it is permitted */
if (write vma-vm_flags VM_MAYWRITE)
- len -= copy_to_user((void *) addr, buf, len);
+ copy_to_user_page(vma, NULL, addr,
+(void *) addr, buf, len);
else if (!write vma-vm_flags VM_MAYREAD)
- len -= copy_from_user(buf, (void *) addr, len);
+ copy_from_user_page(vma, NULL, addr,
+ buf, (void *) addr, len);
else
len = 0;
} else {
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 2/6] NOMMU: Provide per-task stack usage through /proc for NOMMU
Make it possible to get the per-task stack usage through /proc on a NOMMU
system. The MMU-mode routine can't be used because walk_page_range() doesn't
work on NOMMU.
It can be tested to show the stack usages of non-kernel-thread processes:
# grep Stack usage: /proc/*/status | grep -v 0 kB
/proc/1/status:Stack usage: 2 kB
/proc/57/status:Stack usage:3 kB
/proc/58/status:Stack usage:1 kB
/proc/59/status:Stack usage:3 kB
/proc/60/status:Stack usage:5 kB
/proc/self/status:Stack usage: 1 kB
I've only tested it with ELF-FDPIC, though it should work with FLAT too.
Signed-off-by: David Howells dhowe...@redhat.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
Cc: Stefani Seibold stef...@seibold.net
Cc: Paul Mundt let...@linux-sh.org
Cc: Robin Getz rg...@blackfin.uclinux.org
---
fs/proc/array.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 4badde1..c67251e 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -387,8 +387,7 @@ static inline unsigned long get_stack_usage_in_bytes(struct
vm_area_struct *vma,
return ss.usage;
}
-static inline void task_show_stack_usage(struct seq_file *m,
- struct task_struct *task)
+static void task_show_stack_usage(struct seq_file *m, struct task_struct *task)
{
struct vm_area_struct *vma;
struct mm_struct*mm = get_task_mm(task);
@@ -404,9 +403,24 @@ static inline void task_show_stack_usage(struct seq_file
*m,
mmput(mm);
}
}
-#else
+#else /* CONFIG_MMU */
+/*
+ * Calculate the size of a NOMMU process's stack
+ */
static void task_show_stack_usage(struct seq_file *m, struct task_struct *task)
{
+ unsigned long sp, base, usage;
+
+ base = task-stack_start;
+ sp = KSTK_ESP(task);
+
+#ifdef CONFIG_STACK_GROWSUP
+ usage = sp - base;
+#else
+ usage = base - sp;
+#endif
+
+ seq_printf(m, Stack usage:\t%lu kB\n, (usage + 1023) 10);
}
#endif /* CONFIG_MMU */
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 5/6] NOMMU: Use copy_*_user_page() in access_process_vm()
From: Jie Zhang jie.zh...@analog.com
The MMU code uses the copy_*_user_page() variants in access_process_vm()
rather than copy_*_user() as the former includes an icache flush. This is
important when doing things like setting software breakpoints with gdb.
So switch the NOMMU code over to do the same.
This patch makes the reasonable assumption that copy_from_user_page() won't
fail - which is probably fine, as we've checked the VMA from which we're
copying is usable, and the copy is not allowed to cross VMAs. The one case
where it might go wrong is if the VMA is a device rather than RAM, and that
device returns an error which - in which case rubbish will be returned rather
than EIO.
Signed-off-by: Jie Zhang jie.zh...@analog.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
Signed-off-by: David Howells dhowe...@redhat.com
Acked-by: David McCullough david_mccullo...@mcafee.com
Acked-by: Paul Mundt let...@linux-sh.org
Acked-by: Greg Ungerer g...@uclinux.org
---
mm/nommu.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index db52886..1e1ecb2 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1896,9 +1896,11 @@ int access_process_vm(struct task_struct *tsk, unsigned
long addr, void *buf, in
/* only read or write mappings where it is permitted */
if (write vma-vm_flags VM_MAYWRITE)
- len -= copy_to_user((void *) addr, buf, len);
+ copy_to_user_page(vma, NULL, addr,
+(void *) addr, buf, len);
else if (!write vma-vm_flags VM_MAYREAD)
- len -= copy_from_user(buf, (void *) addr, len);
+ copy_from_user_page(vma, NULL, addr,
+ buf, (void *) addr, len);
else
len = 0;
} else {
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: [PATCH] NOMMU: add [stack] label to per-process maps output
Mike Frysinger vapier@gmail.com wrote: but i guess this is no worse than the current ? Indeed. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH] NOMMU: add [stack] label to per-process maps output
Mike Frysinger vap...@gentoo.org wrote: it'd be cool if the global /proc/maps could display something like [stack/pid], but i can't quite divine how to get a mm_struct out of a vm_region without having to walk the entire process list. Tricky. vm_regions can be shared between multiple mm_structs, although in the case of the stack, they're probably not. Furthermore, there's no interface to mmap() to say the region you're allocating belongs to a particular PID (and with userspace created threads, you have to create the stack _before_ calling clone()). That said, you could add a 'creator pid' to the vm_region. This could be set firstly by mmap() to current-pid, and then overridden by clone() for the stack VMA. It would be approximate, but probably a good approximation. You probably don't actually need a back pointer, just an integer PID. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH] NOMMU: add [stack] label to per-process maps output
Mike Frysinger vap...@gentoo.org wrote:
+ if (vma-vm_start = mm-start_brk
+ vma-vm_end = mm-brk) {
Hmmm... That ought to involve mm-start_stack somewhere... (Or, more
probably, task-stack_start:-/)
David
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 1/6] NOMMU: Optimise away the {dac_, }mmap_min_addr tests
In NOMMU mode clamp dac_mmap_min_addr to zero to cause the tests on it to be
skipped by the compiler. We do this as the minimum mmap address doesn't make
any sense in NOMMU mode.
mmap_min_addr and round_hint_to_min() can be discarded entirely in NOMMU mode.
Signed-off-by: David Howells dhowe...@redhat.com
Acked-by: Eric Paris epa...@redhat.com
---
include/linux/security.h |7 +++
kernel/sysctl.c |2 ++
mm/Kconfig |1 +
security/Makefile|3 ++-
4 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/include/linux/security.h b/include/linux/security.h
index 466cbad..2c627d3 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -95,8 +95,13 @@ struct seq_file;
extern int cap_netlink_send(struct sock *sk, struct sk_buff *skb);
extern int cap_netlink_recv(struct sk_buff *skb, int cap);
+#ifdef CONFIG_MMU
extern unsigned long mmap_min_addr;
extern unsigned long dac_mmap_min_addr;
+#else
+#define dac_mmap_min_addr 0UL
+#endif
+
/*
* Values used in the task_security_ops calls
*/
@@ -121,6 +126,7 @@ struct request_sock;
#define LSM_UNSAFE_PTRACE 2
#define LSM_UNSAFE_PTRACE_CAP 4
+#ifdef CONFIG_MMU
/*
* If a hint addr is less than mmap_min_addr change hint to be as
* low as possible but still greater than mmap_min_addr
@@ -135,6 +141,7 @@ static inline unsigned long round_hint_to_min(unsigned long
hint)
}
extern int mmap_min_addr_handler(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t
*ppos);
+#endif
#ifdef CONFIG_SECURITY
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 45e4bef..856a24e 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1214,6 +1214,7 @@ static struct ctl_table vm_table[] = {
.proc_handler = proc_dointvec_jiffies,
},
#endif
+#ifdef CONFIG_MMU
{
.procname = mmap_min_addr,
.data = dac_mmap_min_addr,
@@ -1221,6 +1222,7 @@ static struct ctl_table vm_table[] = {
.mode = 0644,
.proc_handler = mmap_min_addr_handler,
},
+#endif
#ifdef CONFIG_NUMA
{
.procname = numa_zonelist_order,
diff --git a/mm/Kconfig b/mm/Kconfig
index 43ea8c3..ee9f3e0 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -221,6 +221,7 @@ config KSM
config DEFAULT_MMAP_MIN_ADDR
int Low address space to protect from user allocation
+ depends on MMU
default 4096
help
This is the portion of low virtual memory which should be protected
diff --git a/security/Makefile b/security/Makefile
index bb44e35..da20a19 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -8,7 +8,8 @@ subdir-$(CONFIG_SECURITY_SMACK) += smack
subdir-$(CONFIG_SECURITY_TOMOYO)+= tomoyo
# always enable default capabilities
-obj-y += commoncap.o min_addr.o
+obj-y += commoncap.o
+obj-$(CONFIG_MMU) += min_addr.o
# Object file lists
obj-$(CONFIG_SECURITY) += security.o capability.o
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 3/6] FDPIC: Respect PT_GNU_STACK exec protection markings when creating NOMMU stack
From: Mike Frysinger vap...@gentoo.org The current code will load the stack size and protection markings, but then only use the markings in the MMU code path. The NOMMU code path always passes PROT_EXEC to the mmap() call. While this doesn't matter to most people whilst the code is running, it will cause a pointless icache flush when starting every FDPIC application. Typically this icache flush will be of a region on the order of 128KB in size, or may be the entire icache, depending on the facilities available on the CPU. In the case where the arch default behaviour seems to be desired (EXSTACK_DEFAULT), we probe VM_STACK_FLAGS for VM_EXEC to determine whether we should be setting PROT_EXEC or not. For arches that support an MPU (Memory Protection Unit - an MMU without the virtual mapping capability), setting PROT_EXEC or not will make an important difference. It should be noted that this change also affects the executability of the brk region, since ELF-FDPIC has that share with the stack. However, this is probably irrelevant as NOMMU programs aren't likely to use the brk region, preferring instead allocation via mmap(). Signed-off-by: Mike Frysinger vap...@gentoo.org Signed-off-by: David Howells dhowe...@redhat.com --- arch/blackfin/include/asm/page.h |5 + arch/frv/include/asm/page.h |2 -- fs/binfmt_elf_fdpic.c| 13 +++-- 3 files changed, 16 insertions(+), 4 deletions(-) diff --git a/arch/blackfin/include/asm/page.h b/arch/blackfin/include/asm/page.h index 944a07c..1d04e40 100644 --- a/arch/blackfin/include/asm/page.h +++ b/arch/blackfin/include/asm/page.h @@ -10,4 +10,9 @@ #include asm-generic/page.h #define MAP_NR(addr) (((unsigned long)(addr)-PAGE_OFFSET) PAGE_SHIFT) +#define VM_DATA_DEFAULT_FLAGS \ + (VM_READ | VM_WRITE | \ + ((current-personality READ_IMPLIES_EXEC) ? VM_EXEC : 0 ) | \ +VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) + #endif diff --git a/arch/frv/include/asm/page.h b/arch/frv/include/asm/page.h index 25c6a50..8c97068 100644 --- a/arch/frv/include/asm/page.h +++ b/arch/frv/include/asm/page.h @@ -63,12 +63,10 @@ extern unsigned long max_pfn; #define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) PAGE_SHIFT) -#ifdef CONFIG_MMU #define VM_DATA_DEFAULT_FLAGS \ (VM_READ | VM_WRITE | \ ((current-personality READ_IMPLIES_EXEC) ? VM_EXEC : 0 ) | \ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) -#endif #endif /* __ASSEMBLY__ */ diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c index 7b05538..5a3ec95 100644 --- a/fs/binfmt_elf_fdpic.c +++ b/fs/binfmt_elf_fdpic.c @@ -171,6 +171,9 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, #ifdef ELF_FDPIC_PLAT_INIT unsigned long dynaddr; #endif +#ifndef CONFIG_MMU + unsigned long stack_prot; +#endif struct file *interpreter = NULL; /* to shut gcc up */ char *interpreter_name = NULL; int executable_stack; @@ -316,6 +319,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, * defunct, deceased, etc. after this point we have to exit via * error_kill */ set_personality(PER_LINUX_FDPIC); + if (elf_read_implies_exec(exec_params.hdr, executable_stack)) + current-personality |= READ_IMPLIES_EXEC; set_binfmt(elf_fdpic_format); current-mm-start_code = 0; @@ -377,9 +382,13 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, if (stack_size PAGE_SIZE * 2) stack_size = PAGE_SIZE * 2; + stack_prot = PROT_READ | PROT_WRITE; + if (executable_stack == EXSTACK_ENABLE_X || + (executable_stack == EXSTACK_DEFAULT VM_STACK_FLAGS VM_EXEC)) + stack_prot |= PROT_EXEC; + down_write(current-mm-mmap_sem); - current-mm-start_brk = do_mmap(NULL, 0, stack_size, -PROT_READ | PROT_WRITE | PROT_EXEC, + current-mm-start_brk = do_mmap(NULL, 0, stack_size, stack_prot, MAP_PRIVATE | MAP_ANONYMOUS | MAP_UNINITIALIZED | MAP_GROWSDOWN, 0); ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 4/6] NOMMU: Avoiding duplicate icache flushes of shared maps
From: Mike Frysinger vapier@gmail.com
When working with FDPIC, there are many shared mappings of read-only code
regions between applications (the C library, applet packages like busybox,
etc.), but the current do_mmap_pgoff() function will issue an icache flush
whenever a VMA is added to an MM instead of only doing it when the map is
initially created.
The flush can instead be done when a region is first mmapped PROT_EXEC. Note
that we may not rely on the first mapping of a region being executable - it's
possible for it to be PROT_READ only, so we have to remember whether we've
flushed the region or not, and then flush the entire region when a bit of it is
made executable.
However, this also affects the brk area. That will no longer be executable.
We can mprotect() it to PROT_EXEC on MPU-mode kernels, but for NOMMU mode
kernels, when it increases the brk allocation, making sys_brk() flush the extra
from the icache should suffice. The brk area probably isn't used by NOMMU
programs since the brk area can only use up the leavings from the stack
allocation, where the stack allocation is larger than requested.
Signed-off-by: David Howells dhowe...@redhat.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
include/linux/mm_types.h |2 ++
mm/nommu.c | 11 ---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 84a524a..84d020b 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -123,6 +123,8 @@ struct vm_region {
struct file *vm_file; /* the backing file or NULL */
atomic_tvm_usage; /* region usage count */
+ boolvm_icache_flushed : 1; /* true if the icache has been
flushed for
+ * this region */
};
/*
diff --git a/mm/nommu.c b/mm/nommu.c
index 8687973..db52886 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -432,6 +432,7 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)
/*
* Ok, looks good - let it rip.
*/
+ flush_icache_range(mm-brk, brk);
return mm-brk = brk;
}
@@ -1353,10 +1354,14 @@ unsigned long do_mmap_pgoff(struct file *file,
share:
add_vma_to_mm(current-mm, vma);
- up_write(nommu_region_sem);
+ /* we flush the region from the icache only when the first executable
+* mapping of it is made */
+ if (vma-vm_flags VM_EXEC !region-vm_icache_flushed) {
+ flush_icache_range(region-vm_start, region-vm_end);
+ region-vm_icache_flushed = true;
+ }
- if (prot PROT_EXEC)
- flush_icache_range(result, result + len);
+ up_write(nommu_region_sem);
kleave( = %lx, result);
return result;
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 6/6] NOMMU: ramfs: Drop unused local var
From: Mike Frysinger vap...@gentoo.org
Signed-off-by: Mike Frysinger vap...@gentoo.org
Signed-off-by: David Howells dhowe...@redhat.com
---
fs/ramfs/file-nommu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ramfs/file-nommu.c b/fs/ramfs/file-nommu.c
index 32fae40..2efc571 100644
--- a/fs/ramfs/file-nommu.c
+++ b/fs/ramfs/file-nommu.c
@@ -60,7 +60,7 @@ const struct inode_operations ramfs_file_inode_operations = {
*/
int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize)
{
- unsigned long npages, xpages, loop, limit;
+ unsigned long npages, xpages, loop;
struct page *pages;
unsigned order;
void *data;
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH 5/7] NOMMU: Avoiding duplicate icache flushes of shared maps
Jamie Lokier ja...@shareable.org wrote: This looks like it won't work in the following sequence: process A maps MAP_SHARED, PROT_READ|PROT_EXEC (flushes icache) process B maps MAP_SHARED, PROT_READ|PROT_WRITE and proceeds to modify the data process C maps MAP_SHARED, PROT_READ|PROT_EXEC (no icache flush) Assuming all the above refer to the same piece of RAM, there's no reason that process A will will continue to function correctly executing from the first mapping if process B writes to that RAM through the second mapping. There's also no point doing an icache flush unless you first flush the dcache back to the RAM - and we don't know to do that because the O/S does not know whether the RAM has been changed. So we'd have to do an unconditional dcache flush too for the entire RAM segment. I'd prefer to leave this to the writers. If they're mad enough to write shared code that undergoes runtime modification, and then want to run it on NOMMU... So my question back to you is: would it work anyway? Note that some arches have a specific cache flushing system call. Perhaps this should be extended to all. What about icache flushes in these cases: When using mprotect() PROT_READ|PROT_WRITE - PROT_READ|PROT_EXEC, e.g. as an FDPIC implementation may do when updating PLT entries. There is no mprotect() on NOMMU, at least not at the moment. It may be reasonable to add support for someone turning on/off the PROT_EXEC and PROT_WRITE bits, and make it flush dcache to RAM when WRITE is turned off, and flush the icache when EXEC is turned on, in that order. However, as Mike said, we don't do this in FDPIC. The code sections are immutable blobs, and are mapped MAP_PRIVATE, PROT_READ|PROT_EXEC from the start. That way, mmap() will share them for us and even do XIP without special support in userspace. FDPIC uses a non-executable GOT in the data area, and loads the function pointer and new GOT pointer out of it before making a call. And when calling msync(), like this: process A maps MAP_SHARED, PROT_READ|PROT_EXEC (flushes icache) process B maps MAP_SHARED, PROT_READ|PROT_WRITE and proceeds to modify the data process A calls msync() and proceeds to execute the modified contents Similarly, we don't provide msync(). On NOMMU, memory mappings cannot be shared from disks that aren't based direct-access (quasi-)memory (e.g. ramfs, MTD). We could, perhaps, partially implement msync() to flush the appropriate caches. We might even be able to add extra flags to msync() so that it can flush just the CPU caches - that would obviate the need for separate syscalls for this purpose. Do you think the mprotect() and msync() calls should flush icache in those cases? I don't see that msync() should flush the icache at all. It's purpose is to flush data to the backing store. Also, don't forget that under NOMMU conditions, you have no idea if the data has been modified. But in the first example above, I don't see how process C could be expected to know it must flush icache, and process B could just be an optimised with writable mmap file copy, so it shouldn't have responsibility for icache either. It's manually executing off of a MAP_SHARED region, a region that others have open for write. It has to look after its own semantics. This applied too to process A. If seen arguments for it, and arguments that the executing process can be expected to explicitly flush icache itself in those cases because it knows what it is doing. (Personally I lean towards the kernel should be doing it. IRIX interestingly offers both alternatives, with a PROT_EXEC_NOFLUSH). I disagree, at least in the case of MAP_SHARED regions. You need to manage your own coherency. Again, see process A vs process B. Or is icache fully flushed on every context switch on all nommu architectures anyway, and defined to do so? That would be a sure performance killer, and, in any case, wouldn't help on an SMP system. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 1/7] security: do not check mmap_min_addr on nommu systems
From: Eric Paris epa...@redhat.com
nommu systems can do anything with memory they please and so they already
win. mmap_min_addr is the least of their worries. Currently the
mmap_min_addr implementation is problamatic on such systems. This patch
changes the addr_only argument to be a flags which can take the arguments
for addr_only or not_addr. LSMs then need to properly implement these two
flags.
Signed-off-by: Eric Paris epa...@redhat.com
---
include/linux/security.h | 20 ++--
mm/mmap.c|6 --
mm/mremap.c |6 --
mm/nommu.c |3 ++-
security/commoncap.c |7 ---
security/security.c |5 +++--
security/selinux/hooks.c |9 +
7 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/include/linux/security.h b/include/linux/security.h
index 466cbad..e7dc87c 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -43,6 +43,10 @@
#define SECURITY_CAP_NOAUDIT 0
#define SECURITY_CAP_AUDIT 1
+/* sec_flags for security_file_mmap */
+#define SECURITY_MMAP_ONLY_ADDR_CHECK 0x01
+#define SECURITY_MMAP_SKIP_ADDR_CHECK 0x02
+
struct ctl_table;
struct audit_krule;
@@ -69,7 +73,7 @@ extern int cap_inode_need_killpriv(struct dentry *dentry);
extern int cap_inode_killpriv(struct dentry *dentry);
extern int cap_file_mmap(struct file *file, unsigned long reqprot,
unsigned long prot, unsigned long flags,
-unsigned long addr, unsigned long addr_only);
+unsigned long addr, unsigned long sec_flags);
extern int cap_task_fix_setuid(struct cred *new, const struct cred *old, int
flags);
extern int cap_task_prctl(int option, unsigned long arg2, unsigned long arg3,
unsigned long arg4, unsigned long arg5);
@@ -604,11 +608,15 @@ static inline void security_free_mnt_opts(struct
security_mnt_opts *opts)
* Return 0 if permission is granted.
* @file_mmap :
* Check permissions for a mmap operation. The @file may be NULL, e.g.
- * if mapping anonymous memory.
+ * if mapping anonymous memory. This actually performs 2 seperate types
+ * of checks. It first checks permissions on the file in question (if
+ * it exists) and it also checks if the address is allowed.
* @file contains the file structure for file to map (may be NULL).
* @reqprot contains the protection requested by the application.
* @prot contains the protection that will be applied by the kernel.
* @flags contains the operational flags.
+ * @addr address vm will map to
+ * @sec_flags which of the 2 types of checks should (not) be performed
* Return 0 if permission is granted.
* @file_mprotect:
* Check permissions before changing memory access permissions.
@@ -1556,7 +1564,7 @@ struct security_operations {
int (*file_mmap) (struct file *file,
unsigned long reqprot, unsigned long prot,
unsigned long flags, unsigned long addr,
- unsigned long addr_only);
+ unsigned long sec_flags);
int (*file_mprotect) (struct vm_area_struct *vma,
unsigned long reqprot,
unsigned long prot);
@@ -1825,7 +1833,7 @@ void security_file_free(struct file *file);
int security_file_ioctl(struct file *file, unsigned int cmd, unsigned long
arg);
int security_file_mmap(struct file *file, unsigned long reqprot,
unsigned long prot, unsigned long flags,
- unsigned long addr, unsigned long addr_only);
+ unsigned long addr, unsigned long sec_flags);
int security_file_mprotect(struct vm_area_struct *vma, unsigned long reqprot,
unsigned long prot);
int security_file_lock(struct file *file, unsigned int cmd);
@@ -2321,9 +2329,9 @@ static inline int security_file_mmap(struct file *file,
unsigned long reqprot,
unsigned long prot,
unsigned long flags,
unsigned long addr,
-unsigned long addr_only)
+unsigned long sec_flags)
{
- return cap_file_mmap(file, reqprot, prot, flags, addr, addr_only);
+ return cap_file_mmap(file, reqprot, prot, flags, addr, sec_flags);
}
static inline int security_file_mprotect(struct vm_area_struct *vma,
diff --git a/mm/mmap.c b/mm/mmap.c
index 292ddc3..6b933e9 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1664,7 +1664,8 @@ static int expand_downwards(struct vm_area_struct *vma,
return -ENOMEM;
address = PAGE_MASK;
- error = security_file_mmap(NULL, 0, 0, 0, address, 1);
+ error = security_file_mmap(NULL, 0, 0, 0, address,
+
[uClinux-dev] [PATCH 2/7] NOMMU: Provide per-task stack usage through /proc for NOMMU
Make it possible to get the per-task stack usage through /proc on a NOMMU
system. The MMU-mode routine can't be used because walk_page_range() doesn't
work on NOMMU.
It can be tested to show the stack usages of non-kernel-thread processes:
# grep Stack usage: /proc/*/status | grep -v 0 kB
/proc/1/status:Stack usage: 2 kB
/proc/57/status:Stack usage:3 kB
/proc/58/status:Stack usage:1 kB
/proc/59/status:Stack usage:3 kB
/proc/60/status:Stack usage:5 kB
/proc/self/status:Stack usage: 1 kB
I've only tested it with ELF-FDPIC, though it should work with FLAT too.
Signed-off-by: David Howells dhowe...@redhat.com
Cc: Stefani Seibold stef...@seibold.net
Cc: Mike Frysinger vap...@gentoo.org
Cc: Paul Mundt let...@linux-sh.org
Cc: Robin Getz rg...@blackfin.uclinux.org
---
fs/proc/array.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 4badde1..c67251e 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -387,8 +387,7 @@ static inline unsigned long get_stack_usage_in_bytes(struct
vm_area_struct *vma,
return ss.usage;
}
-static inline void task_show_stack_usage(struct seq_file *m,
- struct task_struct *task)
+static void task_show_stack_usage(struct seq_file *m, struct task_struct *task)
{
struct vm_area_struct *vma;
struct mm_struct*mm = get_task_mm(task);
@@ -404,9 +403,24 @@ static inline void task_show_stack_usage(struct seq_file
*m,
mmput(mm);
}
}
-#else
+#else /* CONFIG_MMU */
+/*
+ * Calculate the size of a NOMMU process's stack
+ */
static void task_show_stack_usage(struct seq_file *m, struct task_struct *task)
{
+ unsigned long sp, base, usage;
+
+ base = task-stack_start;
+ sp = KSTK_ESP(task);
+
+#ifdef CONFIG_STACK_GROWSUP
+ usage = sp - base;
+#else
+ usage = base - sp;
+#endif
+
+ seq_printf(m, Stack usage:\t%lu kB\n, (usage + 1023) 10);
}
#endif /* CONFIG_MMU */
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 3/7] NOMMU: fix malloc performance by adding uninitialized flag
From: Jie Zhang jie.zh...@analog.com
The NOMMU code currently clears all anonymous mmapped memory. While this
is what we want in the default case, all memory allocation from userspace
under NOMMU has to go through this interface, including malloc() which is
allowed to return uninitialized memory. This can easily be a significant
performance penalty. So for constrained embedded systems were security is
irrelevant, allow people to avoid clearing memory unnecessarily.
This also alters the ELF-FDPIC binfmt such that it obtains uninitialised
memory for the brk and stack region.
Signed-off-by: Jie Zhang jie.zh...@analog.com
Signed-off-by: Robin Getz rg...@analog.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
Signed-off-by: David Howells dhowe...@redhat.com
---
Documentation/nommu-mmap.txt | 26 ++
fs/binfmt_elf_fdpic.c |3 ++-
include/asm-generic/mman-common.h |5 +
init/Kconfig | 22 ++
mm/nommu.c|8 +---
5 files changed, 60 insertions(+), 4 deletions(-)
diff --git a/Documentation/nommu-mmap.txt b/Documentation/nommu-mmap.txt
index b565e82..8e1ddec 100644
--- a/Documentation/nommu-mmap.txt
+++ b/Documentation/nommu-mmap.txt
@@ -119,6 +119,32 @@ FURTHER NOTES ON NO-MMU MMAP
granule but will only discard the excess if appropriately configured as
this has an effect on fragmentation.
+ (*) The memory allocated by a request for an anonymous mapping will normally
+ be cleared by the kernel before being returned in accordance with the
+ Linux man pages (ver 2.22 or later).
+
+ In the MMU case this can be achieved with reasonable performance as
+ regions are backed by virtual pages, with the contents only being mapped
+ to cleared physical pages when a write happens on that specific page
+ (prior to which, the pages are effectively mapped to the global zero page
+ from which reads can take place). This spreads out the time it takes to
+ initialize the contents of a page - depending on the write-usage of the
+ mapping.
+
+ In the no-MMU case, however, anonymous mappings are backed by physical
+ pages, and the entire map is cleared at allocation time. This can cause
+ significant delays during a userspace malloc() as the C library does an
+ anonymous mapping and the kernel then does a memset for the entire map.
+
+ However, for memory that isn't required to be precleared - such as that
+ returned by malloc() - mmap() can take a MAP_UNINITIALIZED flag to
+ indicate to the kernel that it shouldn't bother clearing the memory before
+ returning it. Note that CONFIG_MMAP_ALLOW_UNINITIALIZED must be enabled
+ to permit this, otherwise the flag will be ignored.
+
+ uClibc uses this to speed up malloc(), and the ELF-FDPIC binfmt uses this
+ to allocate the brk and stack region.
+
(*) A list of all the private copy and anonymous mappings on the system is
visible through /proc/maps in no-MMU mode.
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 38502c6..79d2b1a 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -380,7 +380,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm,
down_write(current-mm-mmap_sem);
current-mm-start_brk = do_mmap(NULL, 0, stack_size,
PROT_READ | PROT_WRITE | PROT_EXEC,
-MAP_PRIVATE | MAP_ANONYMOUS |
MAP_GROWSDOWN,
+MAP_PRIVATE | MAP_ANONYMOUS |
+MAP_UNINITIALIZED | MAP_GROWSDOWN,
0);
if (IS_ERR_VALUE(current-mm-start_brk)) {
diff --git a/include/asm-generic/mman-common.h
b/include/asm-generic/mman-common.h
index 5ee13b2..2011126 100644
--- a/include/asm-generic/mman-common.h
+++ b/include/asm-generic/mman-common.h
@@ -19,6 +19,11 @@
#define MAP_TYPE 0x0f/* Mask for type of mapping */
#define MAP_FIXED 0x10/* Interpret addr exactly */
#define MAP_ANONYMOUS 0x20/* don't use a file */
+#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
+# define MAP_UNINITIALIZED 0x400 /* For anonymous mmap, memory could be
uninitialized */
+#else
+# define MAP_UNINITIALIZED 0x0 /* Don't support this flag */
+#endif
#define MS_ASYNC 1 /* sync memory asynchronously */
#define MS_INVALIDATE 2 /* invalidate the caches */
diff --git a/init/Kconfig b/init/Kconfig
index 54c655c..72e6d10 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1079,6 +1079,28 @@ config SLOB
endchoice
+config MMAP_ALLOW_UNINITIALIZED
+ bool Allow mmaped anonymous memory to be un-initialized
+ depends on EMBEDDED !MMU
+ default n
+ help
+ Normally, and according to the Linux spec, anonymous memory obtained
[uClinux-dev] [PATCH 4/7] FDPIC: Respect PT_GNU_STACK exec protection markings when creating NOMMU stack
From: Mike Frysinger vap...@gentoo.org The current code will load the stack size and protection markings, but then only use the markings in the MMU code path. The NOMMU code path always passes PROT_EXEC to the mmap() call. While this doesn't matter to most people whilst the code is running, it will cause a pointless icache flush when starting every FDPIC application. Typically this icache flush will be of a region on the order of 128KB in size, or may be the entire icache, depending on the facilities available on the CPU. In the case where the arch default behaviour seems to be desired (EXSTACK_DEFAULT), we probe VM_STACK_FLAGS for VM_EXEC to determine whether we should be setting PROT_EXEC or not. For arches that support an MPU (Memory Protection Unit - an MMU without the virtual mapping capability), setting PROT_EXEC or not will make an important difference. It should be noted that this change also affects the executability of the brk region, since ELF-FDPIC has that share with the stack. However, this is probably irrelevant as NOMMU programs aren't likely to use the brk region, preferring instead allocation via mmap(). Signed-off-by: Mike Frysinger vap...@gentoo.org Signed-off-by: David Howells dhowe...@redhat.com --- arch/blackfin/include/asm/page.h |5 + arch/frv/include/asm/page.h |2 -- fs/binfmt_elf_fdpic.c| 13 +++-- 3 files changed, 16 insertions(+), 4 deletions(-) diff --git a/arch/blackfin/include/asm/page.h b/arch/blackfin/include/asm/page.h index 944a07c..1d04e40 100644 --- a/arch/blackfin/include/asm/page.h +++ b/arch/blackfin/include/asm/page.h @@ -10,4 +10,9 @@ #include asm-generic/page.h #define MAP_NR(addr) (((unsigned long)(addr)-PAGE_OFFSET) PAGE_SHIFT) +#define VM_DATA_DEFAULT_FLAGS \ + (VM_READ | VM_WRITE | \ + ((current-personality READ_IMPLIES_EXEC) ? VM_EXEC : 0 ) | \ +VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) + #endif diff --git a/arch/frv/include/asm/page.h b/arch/frv/include/asm/page.h index 25c6a50..8c97068 100644 --- a/arch/frv/include/asm/page.h +++ b/arch/frv/include/asm/page.h @@ -63,12 +63,10 @@ extern unsigned long max_pfn; #define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) PAGE_SHIFT) -#ifdef CONFIG_MMU #define VM_DATA_DEFAULT_FLAGS \ (VM_READ | VM_WRITE | \ ((current-personality READ_IMPLIES_EXEC) ? VM_EXEC : 0 ) | \ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) -#endif #endif /* __ASSEMBLY__ */ diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c index 79d2b1a..db85b42 100644 --- a/fs/binfmt_elf_fdpic.c +++ b/fs/binfmt_elf_fdpic.c @@ -171,6 +171,9 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, #ifdef ELF_FDPIC_PLAT_INIT unsigned long dynaddr; #endif +#ifndef CONFIG_MMU + unsigned long stack_prot; +#endif struct file *interpreter = NULL; /* to shut gcc up */ char *interpreter_name = NULL; int executable_stack; @@ -316,6 +319,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, * defunct, deceased, etc. after this point we have to exit via * error_kill */ set_personality(PER_LINUX_FDPIC); + if (elf_read_implies_exec(exec_params.hdr, executable_stack)) + current-personality |= READ_IMPLIES_EXEC; set_binfmt(elf_fdpic_format); current-mm-start_code = 0; @@ -377,9 +382,13 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, if (stack_size PAGE_SIZE * 2) stack_size = PAGE_SIZE * 2; + stack_prot = PROT_READ | PROT_WRITE; + if (executable_stack == EXSTACK_ENABLE_X || + (executable_stack == EXSTACK_DEFAULT VM_STACK_FLAGS VM_EXEC)) + stack_prot |= PROT_EXEC; + down_write(current-mm-mmap_sem); - current-mm-start_brk = do_mmap(NULL, 0, stack_size, -PROT_READ | PROT_WRITE | PROT_EXEC, + current-mm-start_brk = do_mmap(NULL, 0, stack_size, stack_prot, MAP_PRIVATE | MAP_ANONYMOUS | MAP_UNINITIALIZED | MAP_GROWSDOWN, 0); ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 5/7] NOMMU: Avoiding duplicate icache flushes of shared maps
From: Mike Frysinger vapier@gmail.com
When working with FDPIC, there are many shared mappings of read-only code
regions between applications (the C library, applet packages like busybox,
etc.), but the current do_mmap_pgoff() function will issue an icache flush
whenever a VMA is added to an MM instead of only doing it when the map is
initially created.
The flush can instead be done when a region is first mmapped PROT_EXEC. Note
that we may not rely on the first mapping of a region being executable - it's
possible for it to be PROT_READ only, so we have to remember whether we've
flushed the region or not, and then flush the entire region when a bit of it is
made executable.
However, this also affects the brk area. That will no longer be executable.
We can mprotect() it to PROT_EXEC on MPU-mode kernels, but for NOMMU mode
kernels, when it increases the brk allocation, making sys_brk() flush the extra
from the icache should suffice. The brk area probably isn't used by NOMMU
programs since the brk area can only use up the leavings from the stack
allocation, where the stack allocation is larger than requested.
Signed-off-by: David Howells dhowe...@redhat.com
---
include/linux/mm_types.h |2 ++
mm/nommu.c | 11 ---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 84a524a..84d020b 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -123,6 +123,8 @@ struct vm_region {
struct file *vm_file; /* the backing file or NULL */
atomic_tvm_usage; /* region usage count */
+ boolvm_icache_flushed : 1; /* true if the icache has been
flushed for
+ * this region */
};
/*
diff --git a/mm/nommu.c b/mm/nommu.c
index 1544a65..bffbdfc 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -432,6 +432,7 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)
/*
* Ok, looks good - let it rip.
*/
+ flush_icache_range(mm-brk, brk);
return mm-brk = brk;
}
@@ -1354,10 +1355,14 @@ unsigned long do_mmap_pgoff(struct file *file,
share:
add_vma_to_mm(current-mm, vma);
- up_write(nommu_region_sem);
+ /* we flush the region from the icache only when the first executable
+* mapping of it is made */
+ if (vma-vm_flags VM_EXEC !region-vm_icache_flushed) {
+ flush_icache_range(region-vm_start, region-vm_end);
+ region-vm_icache_flushed = true;
+ }
- if (prot PROT_EXEC)
- flush_icache_range(result, result + len);
+ up_write(nommu_region_sem);
kleave( = %lx, result);
return result;
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 6/7] NOMMU: Use copy_*_user_page() in access_process_vm()
From: Jie Zhang jie.zh...@analog.com
The MMU code uses the copy_*_user_page() variants in access_process_vm()
rather than copy_*_user() as the former includes an icache flush. This is
important when doing things like setting software breakpoints with gdb.
So switch the NOMMU code over to do the same.
This patch makes the reasonable assumption that copy_from_user_page() won't
fail - which is probably fine, as we've checked the VMA from which we're
copying is usable, and the copy is not allowed to cross VMAs. The one case
where it might go wrong is if the VMA is a device rather than RAM, and that
device returns an error which - in which case rubbish will be returned rather
than EIO.
Signed-off-by: Jie Zhang jie.zh...@analog.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
Signed-off-by: David Howells dhowe...@redhat.com
---
mm/nommu.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index bffbdfc..a8c2392 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1897,9 +1897,11 @@ int access_process_vm(struct task_struct *tsk, unsigned
long addr, void *buf, in
/* only read or write mappings where it is permitted */
if (write vma-vm_flags VM_MAYWRITE)
- len -= copy_to_user((void *) addr, buf, len);
+ copy_to_user_page(vma, NULL, addr,
+(void *) addr, buf, len);
else if (!write vma-vm_flags VM_MAYREAD)
- len -= copy_from_user(buf, (void *) addr, len);
+ copy_from_user_page(vma, NULL, addr,
+ buf, (void *) addr, len);
else
len = 0;
} else {
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 7/7] NOMMU: ramfs: Drop unused local var
From: Mike Frysinger vap...@gentoo.org
Signed-off-by: Mike Frysinger vap...@gentoo.org
Signed-off-by: David Howells dhowe...@redhat.com
---
fs/ramfs/file-nommu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ramfs/file-nommu.c b/fs/ramfs/file-nommu.c
index 32fae40..2efc571 100644
--- a/fs/ramfs/file-nommu.c
+++ b/fs/ramfs/file-nommu.c
@@ -60,7 +60,7 @@ const struct inode_operations ramfs_file_inode_operations = {
*/
int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize)
{
- unsigned long npages, xpages, loop, limit;
+ unsigned long npages, xpages, loop;
struct page *pages;
unsigned order;
void *data;
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH] NOMMU: use copy_*_user_page() in access_process_vm()
Mike Frysinger vap...@gentoo.org wrote:
+ copy_to_user_page(vma, NULL, NULL,
+ (void *) addr, buf, len);
...
+ copy_from_user_page(vma, NULL, NULL,
+ buf, (void *) addr, len);
I think this is not correct. The third parameter in both cases (vaddr) is of
unsigned long type (so should be 0 not NULL), and should not be left zero in
any case. I think it should be passed addr. In fact, we should really pass
the second parameter too (page), though for now, I'm happy to leave that NULL.
See attached revision of the patch.
David
---
From: Jie Zhang jie.zh...@analog.com
Subject: [PATCH] NOMMU: Use copy_*_user_page() in access_process_vm()
The MMU code uses the copy_*_user_page() variants in access_process_vm()
rather than copy_*_user() as the former includes an icache flush. This is
important when doing things like setting software breakpoints with gdb.
So switch the NOMMU code over to do the same.
This patch makes the reasonable assumption that copy_from_user_page() won't
fail - which is probably fine, as we've checked the VMA from which we're
copying is usable, and the copy is not allowed to cross VMAs. The one case
where it might go wrong is if the VMA is a device rather than RAM, and that
device returns an error which - in which case rubbish will be returned rather
than EIO.
Signed-off-by: Jie Zhang jie.zh...@analog.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
Signed-off-by: David Howells dhowe...@redhat.com
---
mm/nommu.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index af12270..953800f 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1896,9 +1896,11 @@ int access_process_vm(struct task_struct *tsk, unsigned
long addr, void *buf, in
/* only read or write mappings where it is permitted */
if (write vma-vm_flags VM_MAYWRITE)
- len -= copy_to_user((void *) addr, buf, len);
+ copy_to_user_page(vma, NULL, addr,
+(void *) addr, buf, len);
else if (!write vma-vm_flags VM_MAYREAD)
- len -= copy_from_user(buf, (void *) addr, len);
+ copy_from_user_page(vma, NULL, addr,
+ buf, (void *) addr, len);
else
len = 0;
} else {
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH] NOMMU: use copy_*_user_page() in access_process_vm()
Jie Zhang jie.zh...@analog.com wrote: I agree on using 0 instead of NULL. But for !MMU, I think, vaddr is always as same as addr. So we don't need to pass it? FRV flushes the vaddr because in MMU mode the cache flush instructions take virtual addresses, so if we pass addr as vaddr, I can use the same cache flush code for both modes. I suspect it makes little difference to the amount of code if we pass that rather than 0, as the value is already computed, and either way, it's going to take one instruction to set up the argument. Note that Blackfin assumes that it may use the dst address for flushing - an assumption that isn't valid in MMU mode with a VIVT cache (which I presume Blackfin isn't, but other CPUs are). David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] how to use shared memory shmget() function
Wilfried Busalski w.busal...@lancier-monitoring.de wrote: What is the reason? What can I do? The most likely explanation is that your kernel doesn't have CONFIG_SYSVIPC=y. Have you tried using strace to see whether your program actually tries talking to the kernel? David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing
Jie Zhang jie.zh...@analog.com wrote: There needs to be a mapping covering the SRAM region for the purposes of the Our GDB is still lack of the feature to debug applications using SRAM. So this part of code was not got exercised. So if we remove this line, can this patch got merged? No. Firstly, the piece of storage that gets munmapped isn't used, so unmapping it isn't wrong. What you need to do is to put a mapping over the bit of the SRAM you wish to use and then fill it and use it. Ideally, you'd do this inside of do_mmap_pgoff() - that way those bits of the SRAM can be shared, but I'm not sure how best to do that. But you need to stick a VMA over it so that various checks don't spit EFAULT/EIO at you. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: [PATCH] FDPIC: respect PT_GNU_STACK exec markings when creating NOMMU stack
Mike Frysinger vap...@gentoo.org wrote: + flush_icache_range(mm-brk, brk); return mm-brk = brk; } probably want mm-brk + brk for the second argument Ummm... Why? mm-brk and brk are both addresses - note the return statement where brk just gets assigned to mm-brk. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: [PATCH] FDPIC: respect PT_GNU_STACK exec markings when creating NOMMU stack
Mike Frysinger vapier@gmail.com wrote: i have seen a few apps use brk()/sbrk() to query the size of things (like e2fsprogs) We do actually record the size of the brk segment, so maybe we could icache flush brk as it is increased (if it is increased): diff --git a/mm/nommu.c b/mm/nommu.c index 3754b16..2ea823d 100644 --- a/mm/nommu.c +++ b/mm/nommu.c @@ -432,6 +432,7 @@ SYSCALL_DEFINE1(brk, unsigned long, brk) /* * Ok, looks good - let it rip. */ + flush_icache_range(mm-brk, brk); return mm-brk = brk; } It might also be worth making the availability of brk() a config option under NOMMU. Â Probably VM_DATA_DEFAULT_FLAGS should not include VM_EXEC for either Blackfin or FRV, but it may be required for SH. The if-statement that calls elf_read_implies_exec() will be optimised away unless the arch specifically sets it (which none of FRV, Blackfin or SH do). while true, wont the later personality test (in VM_DATA_DEFAULT_FLAGS) be left there ? guess it's not that big of a deal. I think we could justify altering FRV and Blackfin to get rid of that test, since we don't make use of read-implies-exec in those arches, but I think that should be a separate patch. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH] FDPIC: respect PT_GNU_STACK exec markings when creating NOMMU stack
Mike Frysinger vap...@gentoo.org wrote: that tends to be 128kB of waste. While your patch is reasonable, at least in concept, I don't see where you get this bit of the description from. + (executable_stack EXSTACK_ENABLE_X ? PROT_EXEC : 0), executable_stack might be EXSTACK_DEFAULT, but the default might be to enable stack exec - in which case, this is wrong. I also don't think that the EXSTACK_xxx constants are a bitmask; I think they're an enumeration - in which case you shouldn't be using '' to test them. setup_arg_pages() uses '=='. As far as I can see only powerpc currently defines the behaviour for EXSTACK_DEFAULT. Mostly it seems to depend on VM_STACK_DEFAULT_FLAGS. Further, I think it only matters for MMU and MPU modes, not for NOMMU mode. There is one further consequence of your patch that you don't mention: the brk area _also_ becomes non-executable. In NOMMU, I suspect this is irrelevant, as I'm not sure brk is used at all (should we make sys_brk() return ENOSYS?). How about the attached instead? Probably VM_DATA_DEFAULT_FLAGS should not include VM_EXEC for either Blackfin or FRV, but it may be required for SH. The if-statement that calls elf_read_implies_exec() will be optimised away unless the arch specifically sets it (which none of FRV, Blackfin or SH do). David --- From: Mike Frysinger vap...@gentoo.org Subject: [PATCH] FDPIC: Respect PT_GNU_STACK exec protection markings when creating NOMMU stack The current code will load the stack size and protection markings, but then only use the markings in the MMU code path. The NOMMU code path always passes PROT_EXEC to the mmap() call. While this doesn't matter to most people whilst the code is running, it will cause a pointless icache flush when starting every FDPIC application. Typically this icache flush will be of a region on the order of 128KB in size, or may be the entire icache, depending on the facilities available on the CPU. In the case where the arch default behaviour seems to be desired (EXSTACK_DEFAULT), we probe VM_STACK_FLAGS for VM_EXEC to determine whether we should be setting PROT_EXEC or not. For arches that support an MPU (Memory Protection Unit - an MMU without the virtual mapping capability), setting PROT_EXEC or not will make an important difference. It should be noted that this change also affects the executability of the brk region, since ELF-FDPIC has that share with the stack. However, this is probably irrelevant as NOMMU programs aren't likely to use the brk region, preferring instead allocation via mmap(). Signed-off-by: Mike Frysinger vap...@gentoo.org Signed-off-by: David Howells dhowe...@redhat.com --- arch/blackfin/include/asm/page.h |5 + arch/frv/include/asm/page.h |2 -- fs/binfmt_elf_fdpic.c| 13 +++-- 3 files changed, 16 insertions(+), 4 deletions(-) diff --git a/arch/blackfin/include/asm/page.h b/arch/blackfin/include/asm/page.h index 944a07c..1d04e40 100644 --- a/arch/blackfin/include/asm/page.h +++ b/arch/blackfin/include/asm/page.h @@ -10,4 +10,9 @@ #include asm-generic/page.h #define MAP_NR(addr) (((unsigned long)(addr)-PAGE_OFFSET) PAGE_SHIFT) +#define VM_DATA_DEFAULT_FLAGS \ + (VM_READ | VM_WRITE | \ + ((current-personality READ_IMPLIES_EXEC) ? VM_EXEC : 0 ) | \ +VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) + #endif diff --git a/arch/frv/include/asm/page.h b/arch/frv/include/asm/page.h index 25c6a50..8c97068 100644 --- a/arch/frv/include/asm/page.h +++ b/arch/frv/include/asm/page.h @@ -63,12 +63,10 @@ extern unsigned long max_pfn; #define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) PAGE_SHIFT) -#ifdef CONFIG_MMU #define VM_DATA_DEFAULT_FLAGS \ (VM_READ | VM_WRITE | \ ((current-personality READ_IMPLIES_EXEC) ? VM_EXEC : 0 ) | \ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) -#endif #endif /* __ASSEMBLY__ */ diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c index 56f159b..4bd0a27 100644 --- a/fs/binfmt_elf_fdpic.c +++ b/fs/binfmt_elf_fdpic.c @@ -171,6 +171,9 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, #ifdef ELF_FDPIC_PLAT_INIT unsigned long dynaddr; #endif +#ifndef CONFIG_MMU + unsigned long stack_prot; +#endif struct file *interpreter = NULL; /* to shut gcc up */ char *interpreter_name = NULL; int executable_stack; @@ -316,6 +319,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, * defunct, deceased, etc. after this point we have to exit via * error_kill */ set_personality(PER_LINUX_FDPIC); + if (elf_read_implies_exec(exec_params.hdr, executable_stack)) + current-personality |= READ_IMPLIES_EXEC; set_binfmt(elf_fdpic_format); current-mm-start_code = 0; @@ -377,9 +382,13 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, if (stack_size PAGE_SIZE * 2
[uClinux-dev] Re: [PATCH] NOMMU: use copy_*_user_page() in access_process_vm()
Mike Frysinger vap...@gentoo.org wrote: - len -= copy_to_user((void *) addr, buf, len); + copy_to_user_page(vma, NULL, NULL, + (void *) addr, buf, len); else if (!write vma-vm_flags VM_MAYREAD) - len -= copy_from_user(buf, (void *) addr, len); + copy_from_user_page(vma, NULL, NULL, + buf, (void *) addr, len); Hmmm... With this, len isn't updated anymore, and so it alters the return value of access_process_vm(), and means ptrace_readdata() won't now return -EIO under some circumstances where it used to. I'm not sure that matters, though. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH] NOMMU: use copy_*_user_page() in access_process_vm()
Mike Frysinger vap...@gentoo.org wrote: The mmu code uses the copy_*_user_page() variants in access_process_vm() rather than copy_*_user() as the former includes an icache flush. This is important when doing things like setting software breakpoints with gdb. So switch the nommu code over to do the same. Note that we may only really want to do an icache flush if the target region is mapped executable somewhere. On the other hand, for debugging stuff on an embedded board, it probably doesn't matter. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] TIF_NOTIFY_RESUME on m68k?
Geert Uytterhoeven ge...@linux-m68k.org wrote: These commits broke CONFIG_KEYS=y on m68k, so technically the missing support is a regression compared to 2.6.31. I couldn't work out how to do it. I mentioned that it needed doing in the logs in the hope that someone on the arch list would do it for the missing arches. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH] NOMMU: fix malloc performance by adding uninitialized flag
This seems reasonable. MAP_UNINITIALIZE definitely needs adding to the
general list so that the MMU folks don't steal the bit. I would also call it
MAP_UNINITIALIZED (well, actually, I'd call it MAP_UNINITIALISED:-), otherwise
it looks like you're asking mmap() to uninitialise the memory for you.
Similarly for CONFIG_MMAP_ALLOW_UNINITIALIZE - I'd add a terminal 'D'.
I've also re-written the documenation somewhat and expanded the patch
description to mention the changes to ELF-FDPIC.
David
---
From: Jie Zhang jie.zh...@analog.com
Subject: [PATCH] NOMMU: Fix malloc performance by adding uninitialized flag
The NOMMU code currently clears all anonymous mmapped memory. While this is
what we want in the default case, all memory allocation from userspace under
NOMMU has to go through this interface, including malloc() which is allowed to
return uninitialized memory. This can easily be a significant performance
penalty. So for constrained embedded systems were security is irrelevant,
allow people to avoid clearing memory unnecessarily.
This also alters the ELF-FDPIC binfmt such that it obtains uninitialised
memory for the brk and stack region.
Signed-off-by: Jie Zhang jie.zh...@analog.com
Signed-off-by: Robin Getz rg...@analog.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
Signed-off-by: David Howells dhowe...@redhat.com
---
Documentation/nommu-mmap.txt | 26 ++
fs/binfmt_elf_fdpic.c |3 ++-
include/asm-generic/mman-common.h |5 +
init/Kconfig | 22 ++
mm/nommu.c|8 +---
5 files changed, 60 insertions(+), 4 deletions(-)
diff --git a/Documentation/nommu-mmap.txt b/Documentation/nommu-mmap.txt
index b565e82..b216ced 100644
--- a/Documentation/nommu-mmap.txt
+++ b/Documentation/nommu-mmap.txt
@@ -119,6 +119,32 @@ FURTHER NOTES ON NO-MMU MMAP
granule but will only discard the excess if appropriately configured as
this has an effect on fragmentation.
+ (*) The memory allocated by a request for an anonymous mapping will normally
+ be cleared by the kernel before being returned in accordance with the
+ Linux man pages (ver 2.22 or later)
+
+ In the MMU case this can be achieved with reasonable performance as
+ regions are backed by virtual pages, with the contents only being mapped
+ to cleared physical pages when a write happens on that specific page
+ (prior to which, the pages are effectively mapped to the global zero page
+ from which reads can take place). This spreads out the time it takes to
+ initialize the contents of a page - depending on the write-usage of the
+ mapping.
+
+ In the no-MMU case, however, anonymous mappings are backed by physical
+ pages, and the entire map is cleared at allocation time. This can cause
+ significant delays during a userspace malloc() as the C library does an
+ anonymous mapping and the kernel then does a memset for the entire map.
+
+ However, for memory that isn't required to be precleared - such as that
+ returned by malloc() - mmap() can take a MAP_UNINITIALIZE flag to indicate
+ to the kernel that it shouldn't bother clearing the memory before
+ returning it. Note that CONFIG_MMAP_ALLOW_UNINITIALIZE must be enabled to
+ permit this, otherwise the flag will be ignored.
+
+ uClibc uses this to speed up malloc(), and the ELF-FDPIC binfmt uses this
+ to allocate the brk and stack region.
+
(*) A list of all the private copy and anonymous mappings on the system is
visible through /proc/maps in no-MMU mode.
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index e19b9bb..ab7e57b 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -380,7 +380,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm,
down_write(current-mm-mmap_sem);
current-mm-start_brk = do_mmap(NULL, 0, stack_size,
PROT_READ | PROT_WRITE | PROT_EXEC,
-MAP_PRIVATE | MAP_ANONYMOUS |
MAP_GROWSDOWN,
+MAP_PRIVATE | MAP_ANONYMOUS |
+MAP_UNINITIALIZE | MAP_GROWSDOWN,
0);
if (IS_ERR_VALUE(current-mm-start_brk)) {
diff --git a/include/asm-generic/mman-common.h
b/include/asm-generic/mman-common.h
index 5ee13b2..dddf626 100644
--- a/include/asm-generic/mman-common.h
+++ b/include/asm-generic/mman-common.h
@@ -19,6 +19,11 @@
#define MAP_TYPE 0x0f/* Mask for type of mapping */
#define MAP_FIXED 0x10/* Interpret addr exactly */
#define MAP_ANONYMOUS 0x20/* don't use a file */
+#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZE
+# define MAP_UNINITIALIZE 0x400/* For anonymous mmap, memory could be
uninitialized */
+#else
+# define MAP_UNINITIALIZE 0x0 /* Don't
[uClinux-dev] Re: [PATCH v2] NOMMU: fix malloc performance by adding uninitialized flag
Mike Frysinger vap...@gentoo.org wrote: + bool Allow mmaped anonymous memory to be un-initialized Can you change that to be 'mmapped' and 'uninitialized'? Other than that, it looks good. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] XIP for armnommu with uClinux-2.6
Erwin Authried ea...@softsys.co.at wrote: I have used XIP with armnommu on mtd devices with 2.4, and I want to use XIP with 2.6 now. I have seen David Howell's patches from 2008-9-24 that add the necessary support in MTD. In arch/arm, it looks like arch_get_unmapped_area() is available for arm with mmu only, is it required to implement this for nommu as well to be able to use XIP? arch_get_unmapped_area() find a piece of unmapped _virtual_ memory space that can then be mapped to a physical area, so it doesn't make sense to have an overriding arch one for the NOMMU case: virtual memory is more or less identical with physical memory - and where in virtual memory a mappable object will be places depends entirely on where in physical memory it is. For XIP in NOMMU mode, the device or filesystem driver needs to provide the get_unmapped_area() file op so that the driver can tell mmap() where the object exists physically. This is really an abuse of the API, but it seems to work. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Does uClinux support some kind of architecture with MMU?
jun...@interark.co.jp wrote: First sorry about my poor english. And I am a newbie to the world of linux. Does uClinux support some kind of architecture with MMU? I mean are there some boards with mmu, if we disable the mmu option (or undef CONFIG_MMU), the uClinux can run on it. If you build your programs such that they can run on a CONFIG_MMU=n kernel - using uClibc, for example - then there's no real reason they can't be run on a CONFIG_MMU=y kernel provided the binfmt driver supports it. For example, I routinely use a uClinux environment built for MMU-less FRV kernels with MMU-present boards using the ELF-FDPIC binfmt. I don't think the ELF binfmt will work without an MMU, and I'm not sure the FLAT binfmt will work with one. Or are there some boards can run both uClinux and full linux? Some Fujitsu FRV boards and some Blackfin boards, I think. There may be others. You need an MMU you can disable to run both. As Gavin Lambert said, it depends on what people have got round to implementing support for. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing
Mike Frysinger vap...@gentoo.org wrote: From: Jie Zhang jie.zh...@analog.com The Blackfin port has custom program header flags/addresses for automatically loading regions into the dedicated on-chip SRAM. So add a hook for ports to leverage. Signed-off-by: Jie Zhang jie.zh...@analog.com Signed-off-by: Mike Frysinger vap...@gentoo.org CC: Bernd Schmidt bernds_...@t-online.de Acked-by: David Howells dhowe...@redhat.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] MMU trade-off
Michael Schnell mschn...@lumino.de wrote: Even there is no real technical cause for this, most non-MMU Linux implementations seem not to support several important features needed for doing multithreaded: TLS, NPTL, __tread keyword in C, really user space based FUTEX. TLS, NPTL and userspace FUTEX are all supported by NOMMU FRV in 2.6 kernels at least, so it is possible. I assume __thread is too, but it's not something I've tested. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] MMU trade-off
Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: you can memory map files without a MMU How? It's limited, but everything I could get to work, works. See: Documentation/nommu-mmap.txt David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 0/2] Make the Unevictable LRU available on NOMMU
Lee Schermerhorn lee.schermerh...@hp.com wrote: I just want to point out [again :)] that removing the ramfs pages from the lru will prevent them from being migrated This is less of an issue for NOMMU kernels, since you can't migrate pages that are mapped. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 1/2] NOMMU: There is no mlock() for NOMMU, so don't provide the bits
The mlock() facility does not exist for NOMMU since all mappings are
effectively locked anyway, so we don't make the bits available when they're
not useful.
Signed-off-by: David Howells dhowe...@redhat.com
---
include/linux/page-flags.h | 20 +---
mm/Kconfig |8
mm/internal.h |8 +---
3 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 219a523..61df177 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -96,6 +96,8 @@ enum pageflags {
PG_swapbacked, /* Page is backed by RAM/swap */
#ifdef CONFIG_UNEVICTABLE_LRU
PG_unevictable, /* Page is unevictable */
+#endif
+#ifdef CONFIG_HAVE_MLOCKED_PAGE_BIT
PG_mlocked, /* Page is vma mlocked */
#endif
#ifdef CONFIG_IA64_UNCACHED_ALLOCATOR
@@ -234,20 +236,20 @@ PAGEFLAG_FALSE(SwapCache)
#ifdef CONFIG_UNEVICTABLE_LRU
PAGEFLAG(Unevictable, unevictable) __CLEARPAGEFLAG(Unevictable, unevictable)
TESTCLEARFLAG(Unevictable, unevictable)
+#else
+PAGEFLAG_FALSE(Unevictable) TESTCLEARFLAG_FALSE(Unevictable)
+ SETPAGEFLAG_NOOP(Unevictable) CLEARPAGEFLAG_NOOP(Unevictable)
+ __CLEARPAGEFLAG_NOOP(Unevictable)
+#endif
+#ifdef CONFIG_HAVE_MLOCKED_PAGE_BIT
#define MLOCK_PAGES 1
PAGEFLAG(Mlocked, mlocked) __CLEARPAGEFLAG(Mlocked, mlocked)
TESTSCFLAG(Mlocked, mlocked)
-
#else
-
#define MLOCK_PAGES 0
PAGEFLAG_FALSE(Mlocked)
SETPAGEFLAG_NOOP(Mlocked) TESTCLEARFLAG_FALSE(Mlocked)
-
-PAGEFLAG_FALSE(Unevictable) TESTCLEARFLAG_FALSE(Unevictable)
- SETPAGEFLAG_NOOP(Unevictable) CLEARPAGEFLAG_NOOP(Unevictable)
- __CLEARPAGEFLAG_NOOP(Unevictable)
#endif
#ifdef CONFIG_IA64_UNCACHED_ALLOCATOR
@@ -367,9 +369,13 @@ static inline void __ClearPageTail(struct page *page)
#ifdef CONFIG_UNEVICTABLE_LRU
#define __PG_UNEVICTABLE (1 PG_unevictable)
-#define __PG_MLOCKED (1 PG_mlocked)
#else
#define __PG_UNEVICTABLE 0
+#endif
+
+#ifdef CONFIG_HAVE_MLOCKED_PAGE_BIT
+#define __PG_MLOCKED (1 PG_mlocked)
+#else
#define __PG_MLOCKED 0
#endif
diff --git a/mm/Kconfig b/mm/Kconfig
index a5b7781..8c89597 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -214,5 +214,13 @@ config UNEVICTABLE_LRU
will use one page flag and increase the code size a little,
say Y unless you know what you are doing.
+config HAVE_MLOCK
+ bool
+ default y if MMU=y
+
+config HAVE_MLOCKED_PAGE_BIT
+ bool
+ default y if HAVE_MLOCK=y UNEVICTABLE_LRU=y
+
config MMU_NOTIFIER
bool
diff --git a/mm/internal.h b/mm/internal.h
index 478223b..987bb03 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -63,6 +63,7 @@ static inline unsigned long page_order(struct page *page)
return page_private(page);
}
+#ifdef CONFIG_HAVE_MLOCK
extern long mlock_vma_pages_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end);
extern void munlock_vma_pages_range(struct vm_area_struct *vma,
@@ -71,6 +72,7 @@ static inline void munlock_vma_pages_all(struct
vm_area_struct *vma)
{
munlock_vma_pages_range(vma, vma-vm_start, vma-vm_end);
}
+#endif
#ifdef CONFIG_UNEVICTABLE_LRU
/*
@@ -90,7 +92,7 @@ static inline void unevictable_migrate_page(struct page *new,
struct page *old)
}
#endif
-#ifdef CONFIG_UNEVICTABLE_LRU
+#ifdef CONFIG_HAVE_MLOCKED_PAGE_BIT
/*
* Called only in fault path via page_evictable() for a new page
* to determine if it's being mapped into a LOCKED vma.
@@ -165,7 +167,7 @@ static inline void free_page_mlock(struct page *page)
}
}
-#else /* CONFIG_UNEVICTABLE_LRU */
+#else /* CONFIG_HAVE_MLOCKED_PAGE_BIT */
static inline int is_mlocked_vma(struct vm_area_struct *v, struct page *p)
{
return 0;
@@ -175,7 +177,7 @@ static inline void mlock_vma_page(struct page *page) { }
static inline void mlock_migrate_page(struct page *new, struct page *old) { }
static inline void free_page_mlock(struct page *page) { }
-#endif /* CONFIG_UNEVICTABLE_LRU */
+#endif /* CONFIG_HAVE_MLOCKED_PAGE_BIT */
/*
* Return the mem_map entry representing the 'offset' subpage within
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 2/2] NOMMU: Make CONFIG_UNEVICTABLE_LRU available when CONFIG_MMU=n
Make CONFIG_UNEVICTABLE_LRU available when CONFIG_MMU=n. There's no logical reason it shouldn't be available, and it can be used for ramfs. Signed-off-by: David Howells dhowe...@redhat.com --- mm/Kconfig |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/mm/Kconfig b/mm/Kconfig index 8c89597..b53427a 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -206,7 +206,6 @@ config VIRT_TO_BUS config UNEVICTABLE_LRU bool Add LRU list to track non-evictable pages default y - depends on MMU help Keeps unevictable pages off of the active and inactive pageout lists, so kswapd will not waste CPU time or have its balancing ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH] NOMMU: Pages allocated to a ramfs inode's pagecache may get wrongly discarded
Andrew Morton a...@linux-foundation.org wrote: Was there a specific reason for using the low-level SetPageDirty()? On the write() path, ramfs pages will be dirtied by simple_commit_write()'s set_page_dirty(), which calls __set_page_dirty_no_writeback(). It just so happens that __set_page_dirty_no_writeback() is equivalent to a simple SetPageDirty() - it bypasses all the extra things which we do for normal permanent-storage-backed pages. But I'd have thought that it would be cleaner and more maintainable (albeit a bit slower) to go through the a_ops? It basically boils down to SetPageDirty() with extra overhead, which you pointed out. We're manually manipulating the pagecache for this inode anyway, so does it matter? The main thing I think I'd rather get rid of is: if (!pagevec_add(lru_pvec, page)) __pagevec_lru_add_file(lru_pvec); ... pagevec_lru_add_file(lru_pvec); Which as Peter points out: The ramfs stuff is rather icky in that it adds the pages to the aging list, marks them dirty, but does not provide a writeout method. This will make the paging code scan over them (continuously) trying to clean them, failing that (lack of writeout method) and putting them back on the list. Not requiring the pages to be added to the LRU would be a really good idea. They are not discardable, be it in MMU or NOMMU mode, except when the inode itself is discarded. Furthermore, does it really make sense for ramfs to use do_sync_read/write() and generic_file_aio_read/write(), at least for NOMMU-mode? These add a lot of overhead, and ramfs doesn't really do either direct I/O or AIO. The main point in favour of using these routines is commonality; but they do add a lot of layers of overhead. Does ramfs read/write performance matter than much, I wonder. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] NOMMU: Pages allocated to a ramfs inode's pagecache may get wrongly discarded
From: Enrik Berkhan enrik.berk...@ge.com The pages attached to a ramfs inode's pagecache by truncation from nothing - as done by SYSV SHM for example - may get discarded under memory pressure. The problem is that the pages are not marked dirty. Anything that creates data in an MMU-based ramfs will cause the pages holding that data will cause the set_page_dirty() aop to be called. For the NOMMU-based mmap, set_page_dirty() may be called by write(), but it won't be called by page-writing faults on writable mmaps, and it isn't called by ramfs_nommu_expand_for_mapping() when a file is being truncated from nothing to allocate a contiguous run. The solution is to mark the pages dirty at the point of allocation by the truncation code. Signed-off-by: Enrik Berkhan enrik.berk...@ge.com Signed-off-by: David Howells dhowe...@redhat.com --- fs/ramfs/file-nommu.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/fs/ramfs/file-nommu.c b/fs/ramfs/file-nommu.c index b9b567a..90d72be 100644 --- a/fs/ramfs/file-nommu.c +++ b/fs/ramfs/file-nommu.c @@ -114,6 +114,9 @@ int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize) if (!pagevec_add(lru_pvec, page)) __pagevec_lru_add_file(lru_pvec); + /* prevent the page from being discarded on memory pressure */ + SetPageDirty(page); + unlock_page(page); } ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
Jamie Lokier ja...@shareable.org wrote: On uClinux with no MMU, you have to use FLT format (all architectures support this I think) or FDPIC-ELF (just a few architectures support this, the advantage is proper shared libraries and loadable modules). FRV does not support FLAT format, only FDPIC-ELF. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] XIP on uclinux 2.6, fantasy or reality?
Michael Schnell [EMAIL PROTECTED] wrote: The main problem is that the region that you want to map for execution *must* be contiguous. That is obvious. Yep. Just making it explicit as it is the problem from which everything else has to flow. ramfs doesn't currently guarantee that unless you truncate the file before filling it, Of course not. Does the XIP aware executable loader automatically decide for any file to be started if it is contiguous and this can be handled XIP or if it is fragmented and thus needs to be copied ? As things stand, the loader cannot find out whether the ramfs backing store is fragmented or not. What both the kernel binfmt and the loader do at the moment is to ask the kernel to do a private, R/O, executable mmap of the code section, and then the NOMMU mmap deals with copying it or XIP'ing it. but since the initramfs packer is in the kernel, that oughtn't to be a problem. Do you mean unpacker ? Yes, sorry. I suppose the likelihood that the initramfs generator in the Kernel creates a fragmented file is very small, as it always starts with an empty file system. And lots of contiguous free memory, yes, but the unpacker uses sys_write(), and the result is subject to the vagaries of the VFS, the VM (what there is of it) and the page allocator. But OTOH, there might be an issue with file data blocks. The initramfs does not really need to use a certain block size for the files, but maybe the XIP loader requests the files to be aligned at certain boundaries. The files are copied into pages attached to the ramfs inodes. They will be appropriately page aligned. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] XIP on uclinux 2.6, fantasy or reality?
Michael Schnell [EMAIL PROTECTED] wrote: Thanks a lot for helping on this issue. Glad to help. Unfortunately, AFAIK, there are compiler issues that prevent full PIC and thus XIP that need to be resolved. Yeah... Does NIOS use the FLAT binfmt? David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] XIP on uclinux 2.6, fantasy or reality?
Gavin Lambert [EMAIL PROTECTED] wrote: As far as I was aware, that's not true. Regardless of filesystem (ramfs or other), if XIP isn't enabled then an *extra* copy of the executable will get loaded into RAM when it's run. You have to have a guarantee that someone won't attempt to modify the file under you. I suppose the ETXTBSY checks ought to deal with that. Currently, if you try to make a shared mmap of a contiguous set of pages in a ramfs file, it will work as expected and map the ramfs's backing store directly, so I suppose there's no reason the same shouldn't be possible for shareable read-only/executable mappings. The main problem is that the region that you want to map for execution *must* be contiguous. ramfs doesn't currently guarantee that unless you truncate the file before filling it, but since the initramfs packer is in the kernel, that oughtn't to be a problem. I'll have a look. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] XIP on uclinux 2.6, fantasy or reality?
Michael Schnell [EMAIL PROTECTED] wrote:
It would be most useful if it would work on initramfs, as this (IMHO) nowadays
(with cheap RAM available) is the most important boot strategy
(decompressing/loading the important files from ROM during the boot, rather
than directly using a flash file system in realtime).
I would be _very_ interested in seeing XIP on initramfs for the NIOS
architecture !
Okay... I think the attached patch should do the trick.
David
---
[PATCH] NOMMU: Support XIP on initramfs
From: David Howells [EMAIL PROTECTED]
Support XIP on files unpacked from the initramfs image on NOMMU systems. This
simply requires the length of the file to be preset so that the ramfs fs can
attempt to garner sufficient contiguous storage to store the file (NOMMU mmap
can only map contiguous RAM).
All the other bits to do XIP on initramfs files are present:
(1) ramfs's truncate attempts to allocate a contiguous run of pages when a
file is truncated upwards from nothing.
(2) ramfs sets BDI on its files to indicate direct mapping is possible, and
that its files can be mapped for read, write and exec.
(3) NOMMU mmap() will use the above bits to determine that it can do XIP.
Possibly this needs better controls, because it will _always_ try and do
XIP.
One disadvantage of this very simplistic approach is that sufficient space
will be allocated to store the whole file, and not just the bit that would be
XIP'd. To deal with this, though, the initramfs unpacker would have to be
able to parse the file contents.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
init/initramfs.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/init/initramfs.c b/init/initramfs.c
index 644fc01..c2e79d4 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -271,6 +271,7 @@ static int __init do_name(void)
if (wfd = 0) {
sys_fchown(wfd, uid, gid);
sys_fchmod(wfd, mode);
+ sys_ftruncate(wfd, body_len);
state = CopyFile;
}
}
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 4/4] MTD: Fix a bad dependency in the Blackfin code
Steve Longerbeam [EMAIL PROTECTED] wrote:
It seems that in the case of a private mapping over a directly-mappable
backing store, the only requirement is that it be read-only. Is that correct?
More to the point, we mustn't have a private writable mapping mapped directly
to the backing device, otherwise any changes made to that mapping will affect
the backing store, and that's incorrect.
Actually, that's not the only requirement. If the process doing the mapping is
under the influence of a debugger, sharing of private mappings is disabled on
the theory that the debugger might want to modify them (determine_vm_flags()).
If so, that check was already made in validate_mmap_request()
(BDI_CAP_MAP_DIRECT is cleared if requesting a read/write mapping).
Yes.
So if we get to the private file mapping for a directly mappable backing
store case in determine_vm_flags(), we know at this point that it is also a
read-only mapping.
That is true.
- else if vm_flags capabilities) ^ vm_flags)
BDI_CAP_VMFLAGS) == 0)
+ else {
Both of these are incorrect, I think.
In the former (which you're replacing), the condition boils down to:
(capabilities BDI_CAP_VMFLAGS) == BDI_CAP_VMFLAGS
In the latter (your replacement), doesn't take account of the capabilities of
the backing device. Direct writeability isn't the only thing that must be
checked; direct readability and direct executability also ought to be checked.
I need to think about this some more.
David
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev][Failed Hunks] [PATCH 1/4] NOMMU: Present backing device capabilities for MTD chardevs
rwarner [EMAIL PROTECTED] wrote: Hunk failed, do not have mtdsuper.o on line to have ntdbdi.o added. Is this soemthing i will need or am missing? Searching the 2007 distro did no reveal this object( or source). Hunk failed when applied against what? My patches apply fine against Linus's cutting-edge kernel. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] XIP on uclinux 2.6, fantasy or reality?
Michael Schnell [EMAIL PROTECTED] wrote: I would be _very_ interested in seeing XIP on initramfs for the NIOS architecture ! If the initramfs image is compressed, then you can't do XIP from it. Once it's loaded into ramfs, then XIP is unnecessary. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] XIP on uclinux 2.6, fantasy or reality?
Jun Sun [EMAIL PROTECTED] wrote: That seems to indicate XIP does not work at all for 2.6. Can someone confirm? It depends. It may work from ramfs, if the pages for each individual shareable mapping are contiguous. It won't work for ROMFS on MTD without patches, and those are currently pending on the MTD maintainer. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] XIP on uclinux 2.6, fantasy or reality?
Jamie Lokier [EMAIL PROTECTED] wrote: Fwiw, on 2.4 I use an in-house ramfs-like driver which allocates the pages contiguously for each file, and that works nicely. But that's not XIP. The 2.6 mmap code will attempt to do that for you for private R/O sections and then share them if possible behind the scenes. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] XIP on uclinux 2.6, fantasy or reality?
Jamie Lokier [EMAIL PROTECTED] wrote: It's not XIP in ROM, but is sharing code segments in RAM in the same way (and same compiler options), which is critical for my application. It reduces no-MMU fragmentation considerably. I know. The ELF-FDPIC binfmt was developed alongside the revised NOMMU code. You say private R/O - not shared R/O? Shared R/O must be effectively shared with the backing store, so copies are explicitly _not_ taken. Private and shared R/O are both capable of XIP if the backing device supports it (as specified in mapping-backing_dev_info-capabilities by the BDI_CAP_ flags). Note that in 2.6 both the ELF-FDPIC and FLAT binfmt drivers use private R/O mappings for their text segments. This permits copies of the code to be taken, and also permits ptrace attachment to prevent copies being taken. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] XIP on uclinux 2.6, fantasy or reality?
rwarner [EMAIL PROTECTED] wrote: Not working for our uClinux build either, v2007-dist and v2.6 kernel on arm with no mmu. Previously reported it was, but was a communication error between myself and coworker. Any idea on the difficulty of the port from 2.4 to 2.6? The magic romptr hook is redundant. It is possible to do the same with get_unmapped_area() and BDI flags. There are patches to make this work with MTD, but they're waiting on the MTD maintainer. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 1/4] NOMMU: Present backing device capabilities for MTD chardevs
Present backing device capabilities for MTD character device files to allow
NOMMU mmap to do direct mapping where possible.
Signed-off-by: David Howells [EMAIL PROTECTED]
Tested-by: Bernd Schmidt [EMAIL PROTECTED]
---
drivers/mtd/Makefile |2 +
drivers/mtd/chips/map_ram.c | 17 +++
drivers/mtd/chips/map_rom.c | 17 +++
drivers/mtd/devices/mtdram.c | 14 +
drivers/mtd/internal.h | 17 +++
drivers/mtd/mtdbdi.c | 43 +
drivers/mtd/mtdchar.c| 63 +-
drivers/mtd/mtdcore.c| 15 ++
drivers/mtd/mtdpart.c| 15 ++
include/linux/mtd/mtd.h | 14 +
10 files changed, 215 insertions(+), 2 deletions(-)
create mode 100644 drivers/mtd/internal.h
create mode 100644 drivers/mtd/mtdbdi.c
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 4b77335..3dcd38f 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -4,7 +4,7 @@
# Core functionality.
obj-$(CONFIG_MTD) += mtd.o
-mtd-y := mtdcore.o mtdsuper.o
+mtd-y := mtdcore.o mtdsuper.o mtdbdi.o
mtd-$(CONFIG_MTD_PARTITIONS) += mtdpart.o
obj-$(CONFIG_MTD_CONCAT) += mtdconcat.o
diff --git a/drivers/mtd/chips/map_ram.c b/drivers/mtd/chips/map_ram.c
index 072dd8a..6bdc50c 100644
--- a/drivers/mtd/chips/map_ram.c
+++ b/drivers/mtd/chips/map_ram.c
@@ -21,6 +21,8 @@ static int mapram_write (struct mtd_info *, loff_t, size_t,
size_t *, const u_ch
static int mapram_erase (struct mtd_info *, struct erase_info *);
static void mapram_nop (struct mtd_info *);
static struct mtd_info *map_ram_probe(struct map_info *map);
+static unsigned long mapram_unmapped_area(struct mtd_info *, unsigned long,
+ unsigned long, unsigned long);
static struct mtd_chip_driver mapram_chipdrv = {
@@ -64,6 +66,7 @@ static struct mtd_info *map_ram_probe(struct map_info *map)
mtd-type = MTD_RAM;
mtd-size = map-size;
mtd-erase = mapram_erase;
+ mtd-get_unmapped_area = mapram_unmapped_area;
mtd-read = mapram_read;
mtd-write = mapram_write;
mtd-sync = mapram_nop;
@@ -79,6 +82,20 @@ static struct mtd_info *map_ram_probe(struct map_info *map)
}
+/*
+ * Allow NOMMU mmap() to directly map the device (if not NULL)
+ * - return the address to which the offset maps
+ * - return -ENOSYS to indicate refusal to do the mapping
+ */
+static unsigned long mapram_unmapped_area(struct mtd_info *mtd,
+ unsigned long len,
+ unsigned long offset,
+ unsigned long flags)
+{
+ struct map_info *map = mtd-priv;
+ return (unsigned long) map-virt + offset;
+}
+
static int mapram_read (struct mtd_info *mtd, loff_t from, size_t len, size_t
*retlen, u_char *buf)
{
struct map_info *map = mtd-priv;
diff --git a/drivers/mtd/chips/map_rom.c b/drivers/mtd/chips/map_rom.c
index 821d0ed..53ce799 100644
--- a/drivers/mtd/chips/map_rom.c
+++ b/drivers/mtd/chips/map_rom.c
@@ -19,6 +19,8 @@ static int maprom_read (struct mtd_info *, loff_t, size_t,
size_t *, u_char *);
static int maprom_write (struct mtd_info *, loff_t, size_t, size_t *, const
u_char *);
static void maprom_nop (struct mtd_info *);
static struct mtd_info *map_rom_probe(struct map_info *map);
+static unsigned long maprom_unmapped_area(struct mtd_info *, unsigned long,
+ unsigned long, unsigned long);
static struct mtd_chip_driver maprom_chipdrv = {
.probe = map_rom_probe,
@@ -39,6 +41,7 @@ static struct mtd_info *map_rom_probe(struct map_info *map)
mtd-name = map-name;
mtd-type = MTD_ROM;
mtd-size = map-size;
+ mtd-get_unmapped_area = maprom_unmapped_area;
mtd-read = maprom_read;
mtd-write = maprom_write;
mtd-sync = maprom_nop;
@@ -51,6 +54,20 @@ static struct mtd_info *map_rom_probe(struct map_info *map)
}
+/*
+ * Allow NOMMU mmap() to directly map the device (if not NULL)
+ * - return the address to which the offset maps
+ * - return -ENOSYS to indicate refusal to do the mapping
+ */
+static unsigned long maprom_unmapped_area(struct mtd_info *mtd,
+ unsigned long len,
+ unsigned long offset,
+ unsigned long flags)
+{
+ struct map_info *map = mtd-priv;
+ return (unsigned long) map-virt + offset;
+}
+
static int maprom_read (struct mtd_info *mtd, loff_t from, size_t len, size_t
*retlen, u_char *buf)
{
struct map_info *map = mtd-priv;
diff --git a/drivers/mtd/devices/mtdram.c b/drivers/mtd/devices/mtdram.c
index 3aaca88..fce5ff7 100644
--- a/drivers/mtd/devices/mtdram.c
+++ b/drivers/mtd/devices
[uClinux-dev] [PATCH 2/4] NOMMU: Add support for direct mapping through mtdconcat if possible
Add support for direct mapping through mtdconcat, if possible, by attaching the
samebacking_dev_info structure to the master.
It has some restrictions:
(1) It won't permit direct mapping of concatenated devices that have differing
BDIs.
(2) It doesn't support maps that span the 'gap' between devices, although it
possibly could if the devices spanned across return compatible
(ie. contiguous) addresses from their get_unmapped_area() ops.
Signed-off-by: Gavin Lambert [EMAIL PROTECTED]
Signed-off-by: David Howells [EMAIL PROTECTED]
Tested-by: Bernd Schmidt [EMAIL PROTECTED]
---
drivers/mtd/mtdconcat.c | 47 +++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c
index 2972a5e..0967984 100644
--- a/drivers/mtd/mtdconcat.c
+++ b/drivers/mtd/mtdconcat.c
@@ -13,6 +13,7 @@
#include linux/slab.h
#include linux/sched.h
#include linux/types.h
+#include linux/backing-dev.h
#include linux/mtd/mtd.h
#include linux/mtd/concat.h
@@ -684,6 +685,40 @@ static int concat_block_markbad(struct mtd_info *mtd,
loff_t ofs)
}
/*
+ * try to support NOMMU mmaps on concatenated devices
+ * - we don't support subdev spanning as we can't guarantee it'll work
+ */
+static unsigned long concat_get_unmapped_area(struct mtd_info *mtd,
+ unsigned long len,
+ unsigned long offset,
+ unsigned long flags)
+{
+ struct mtd_concat *concat = CONCAT(mtd);
+ int i;
+
+ for (i = 0; i concat-num_subdev; i++) {
+ struct mtd_info *subdev = concat-subdev[i];
+
+ if (offset = subdev-size) {
+ offset -= subdev-size;
+ continue;
+ }
+
+ /* we've found the subdev over which the mapping will reside */
+ if (offset + len subdev-size)
+ return (unsigned long) -EINVAL;
+
+ if (subdev-get_unmapped_area)
+ return subdev-get_unmapped_area(subdev, len, offset,
+flags);
+
+ break;
+ }
+
+ return (unsigned long) -ENOSYS;
+}
+
+/*
* This function constructs a virtual MTD device by concatenating
* num_devs MTD devices. A pointer to the new device object is
* stored to *new_dev upon success. This function does _not_
@@ -740,6 +775,8 @@ struct mtd_info *mtd_concat_create(struct mtd_info
*subdev[], /* subdevices to c
concat-mtd.ecc_stats.badblocks = subdev[0]-ecc_stats.badblocks;
+ concat-mtd.backing_dev_info = subdev[0]-backing_dev_info;
+
concat-subdev[0] = subdev[0];
for (i = 1; i num_devs; i++) {
@@ -766,6 +803,15 @@ struct mtd_info *mtd_concat_create(struct mtd_info
*subdev[], /* subdevices to c
concat-mtd.flags |=
subdev[i]-flags MTD_WRITEABLE;
}
+
+ /* only permit direct mapping if the BDIs are all the same
+* - copy-mapping is still permitted
+*/
+ if (concat-mtd.backing_dev_info !=
+ subdev[i]-backing_dev_info)
+ concat-mtd.backing_dev_info =
+ default_backing_dev_info;
+
concat-mtd.size += subdev[i]-size;
concat-mtd.ecc_stats.badblocks +=
subdev[i]-ecc_stats.badblocks;
@@ -796,6 +842,7 @@ struct mtd_info *mtd_concat_create(struct mtd_info
*subdev[], /* subdevices to c
concat-mtd.unlock = concat_unlock;
concat-mtd.suspend = concat_suspend;
concat-mtd.resume = concat_resume;
+ concat-mtd.get_unmapped_area = concat_get_unmapped_area;
/*
* Combine the erase block size info of the subdevices:
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 4/4] MTD: Fix a bad dependency in the Blackfin code
From: Bernd Schmidt [EMAIL PROTECTED] Fix a bad dependency in the Blackfin code on a RomFS config symbol that doesn't exist upstream. Signed-off-by: Bernd Schmidt [EMAIL PROTECTED] Signed-off-by: David Howells [EMAIL PROTECTED] Tested-by: Bernd Schmidt [EMAIL PROTECTED] --- arch/blackfin/kernel/process.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/blackfin/kernel/process.c b/arch/blackfin/kernel/process.c index 77800dd..44ee204 100644 --- a/arch/blackfin/kernel/process.c +++ b/arch/blackfin/kernel/process.c @@ -325,7 +325,7 @@ int _access_ok(unsigned long addr, unsigned long size) if (addr = memory_mtd_end (addr + size) = physical_mem_end) return 1; -#ifdef CONFIG_ROMFS_MTD_FS +#ifdef CONFIG_ROMFS_ON_MTD /* For XIP, allow user space to use pointers within the ROMFS. */ if (addr = memory_mtd_start (addr + size) = memory_mtd_end) return 1; ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 3/4] NOMMU: Make it possible for RomFS to use MTD devices directly
Change RomFS so that it can use MTD devices directly - without the intercession of the block layer - as well as using block devices. This permits RomFS: (1) to use the MTD direct mapping facility available under NOMMU conditions if the underlying device is directly accessible by the CPU (including XIP); (2) and thus to be used when the block layer is disabled. RomFS can be configured with support just for MTD devices, just for Block devices or for both. If RomFS is configured for both, then it will treat mtdblock device files as MTD backing stores, not block layer backing stores. I tested this using a CONFIG_MMU=n CONFIG_BLOCK=n kernel running on my FRV board with a RomFS image installed on the mtdram test device. I see my test program being run XIP: # cat /proc/maps ... c0c000b0-c0c01f8c r-xs 1f:00 144/mnt/doshm ... GDB on the kernel can be used to show that these addresses are within the set-aside RAM space. Signed-off-by: David Howells [EMAIL PROTECTED] Tested-by: Bernd Schmidt [EMAIL PROTECTED] --- fs/Kconfig| 26 ++ fs/romfs/Makefile |9 + fs/romfs/inode.c | 666 - fs/romfs/internal.h | 47 +++ fs/romfs/mmap-nommu.c | 75 ++ fs/romfs/storage.c| 261 +++ fs/romfs/super.c | 649 7 files changed, 1063 insertions(+), 670 deletions(-) delete mode 100644 fs/romfs/inode.c create mode 100644 fs/romfs/internal.h create mode 100644 fs/romfs/mmap-nommu.c create mode 100644 fs/romfs/storage.c create mode 100644 fs/romfs/super.c diff --git a/fs/Kconfig b/fs/Kconfig index abccb5d..8852813 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -507,7 +507,6 @@ config DNOTIFY that uses signals to communicate events to user-space. There exist superior alternatives, but some applications may still rely on dnotify. - If unsure, say Y. config INOTIFY @@ -1441,7 +1440,7 @@ config QNX4FS_RW config ROMFS_FS tristate ROM file system support - depends on BLOCK + depends on BLOCK || MTD ---help--- This is a very small read-only file system mainly intended for initial ram disks of installation disks, but it could be used for @@ -1456,6 +1455,29 @@ config ROMFS_FS If you don't know whether you need it, then you don't need it: answer N. +config ROMFS_ON_BLOCK + bool Block device-backed ROM file system support if (ROMFS_ON_MTD EMBEDDED) + depends on ROMFS_FS BLOCK + help + This permits ROMFS to use block devices buffered through the page + cache as the medium from which to retrieve data. It does not allow + direct mapping of the medium. + + If unsure, answer Y. + +config ROMFS_ON_MTD + bool MTD-backed ROM file system support + depends on ROMFS_FS + depends on MTD=y || (ROMFS_FS=m MTD) + help + This permits ROMFS to use MTD based devices directly, without the + intercession of the block layer (which may have been disabled). It + also allows direct mapping of MTD devices through romfs files under + NOMMU conditions if the underlying device is directly addressable by + the CPU. + + If unsure, answer Y. + config SYSV_FS tristate System V/Xenix/V7/Coherent file system support diff --git a/fs/romfs/Makefile b/fs/romfs/Makefile index c95b21c..420beb7 100644 --- a/fs/romfs/Makefile +++ b/fs/romfs/Makefile @@ -1,7 +1,12 @@ # -# Makefile for the linux romfs filesystem routines. +# Makefile for the linux RomFS filesystem routines. # obj-$(CONFIG_ROMFS_FS) += romfs.o -romfs-objs := inode.o +romfs-y := storage.o super.o + +ifneq ($(CONFIG_MMU),y) +romfs-$(CONFIG_ROMFS_ON_MTD) += mmap-nommu.o +endif + diff --git a/fs/romfs/inode.c b/fs/romfs/inode.c deleted file mode 100644 index 60d2f82..000 --- a/fs/romfs/inode.c +++ /dev/null @@ -1,666 +0,0 @@ -/* - * ROMFS file system, Linux implementation - * - * Copyright (C) 1997-1999 Janos Farkas [EMAIL PROTECTED] - * - * Using parts of the minix filesystem - * Copyright (C) 1991, 1992 Linus Torvalds - * - * and parts of the affs filesystem additionally - * Copyright (C) 1993 Ray Burr - * Copyright (C) 1996 Hans-Joachim Widmaier - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version - * 2 of the License, or (at your option) any later version. - * - * Changes - * Changed for 2.1.19 modules - * Jan 1997Initial release - * Jun 19972.1.43+ changes - * Proper page locking in readpage - * Changed to work with 2.1.45
Re: [uClinux-dev] XIP on uclinux 2.6, fantasy or reality?
rwarner [EMAIL PROTECTED] wrote: Are the patches supplied only for 20080808 or will they also work with the 2007 version? I don't know. I'll have to grab it and find out. I think there's a good chance they will work. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH] NOMMU: Fix SYSV IPC SHM
Allen Yang [EMAIL PROTECTED] wrote: Does this patch fix the problem I mentioned in my previous emails uClinux supports shared memory IPC? No. This fixes a bug introduced by the recent fault handler revision patches from Nick Piggin. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] NOMMU: Fix SYSV IPC SHM
From: David Howells [EMAIL PROTECTED]
Fix the SYSV IPC SHM to work with the changes applied by the new fault handler
patches when CONFIG_MMU=n.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
fs/ramfs/file-nommu.c |7 ++-
ipc/shm.c |2 ++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/fs/ramfs/file-nommu.c b/fs/ramfs/file-nommu.c
index cad2b7a..237fe8b 100644
--- a/fs/ramfs/file-nommu.c
+++ b/fs/ramfs/file-nommu.c
@@ -295,5 +295,10 @@ unsigned long ramfs_nommu_get_unmapped_area(struct file
*file,
*/
int ramfs_nommu_mmap(struct file *file, struct vm_area_struct *vma)
{
- return vma-vm_flags VM_SHARED ? 0 : -ENOSYS;
+ if (!(vma-vm_flags VM_SHARED))
+ return -ENOSYS;
+
+ file_accessed(file);
+ vma-vm_ops = generic_file_vm_ops;
+ return 0;
}
diff --git a/ipc/shm.c b/ipc/shm.c
index d0259e3..d88ac5a 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -268,7 +268,9 @@ static int shm_mmap(struct file * file, struct
vm_area_struct * vma)
if (ret != 0)
return ret;
sfd-vm_ops = vma-vm_ops;
+#ifdef CONFIG_MMU
BUG_ON(!sfd-vm_ops-fault);
+#endif
vma-vm_ops = shm_vm_ops;
shm_open(vma);
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] uClinux supports shared memory IPC?
Allen Yang [EMAIL PROTECTED] wrote: What was errno? No error/warning messages. From the return value (-1), I know shared memory creation failed. Yes, but without knowing the error put in errno by shmget(), it's difficult to say why it failed. shmget(4096, 4096, IPC_CREAT|0x1b6|0666) = -1 EINVAL (Invalid argument) strace shows that error EINVAL was returned. I tried putting printk() in do_shmat(), sys_shmget(), shm_init() in ipc/shm.c. I found that shm_init() was called, but do_shmat() and sys_shmget() were NOT called. Hmmm... Can you put a few printk()'s in arch/m68knommu/kernel/sys_m68k.c, in sys_ipc()? Can you print the call ID on entry, and put a printk() by each error return so that you can tell which it returns through? David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] uClinux supports shared memory IPC?
Gerrit Binnenmars [EMAIL PROTECTED] wrote: - mkdir /dev/shm - mount -t tmpfs tmpfs /dev/shm These two steps ought to be unnecessary as init_tmpfs() in mm/tiny-shmem.c creates the superblock by doing an internal mount. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] mmap inconsistent
Robert Daniels [EMAIL PROTECTED] wrote: I've got a board running linux 2.4.x on an xscale IXP420 with NVRAM on the expansion bus. Are you running with or without an MMU? I'm not sure msync() does anything if there's no MMU. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] uClinux supports shared memory IPC?
Allen Yang [EMAIL PROTECTED] wrote: Some people said MCF5329 doesn't have MMU so that it doesn't support shared memory IPC. Other people said shared memory IPC can be used even without MMU. Anybody here can verify if MCF5329 without MMU can use shared memory IPC? It can be used, but it depends on the kernel you're using. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Begging for help -- where to change memory map --- PLEASE
Mike Dorin [EMAIL PROTECTED] wrote: Inside make menuconfig I have changed address. I have done a search and replace...and everywhere I find the DRAM base I changed it. Yet, somehow, my image is still built to the old address. You may need to check your linker scripts - search for vmlinux.lds.S under the arch of your choice. It would also be helpful to the people here if you could indicate what arch you're dealing with. Including your .config file in the email would be useful in that respect. David ___ uClinux-dev mailing list [EMAIL PROTECTED] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [EMAIL PROTECTED] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: AW: AW: [uClinux-dev] Please help clarifying vfork
Wolf, Josef [EMAIL PROTECTED] wrote: I've just checked uClibc. It uses alloca only when a MMU is available. If there's no MMU, it falls back to mmap(). That's a bit of a problem surely as you can't free the mappings later. Now I'm somewhat confused. What's wrong with alloca in the vfork context? The only problem I can think of is that alloca() allocates from the stack, and with NOMMU-mode you've got a limited stack space and no hope of expanding it if you don't have enough. Maybe the problem is coupled with setjmp implementations of vfork? I found http://gcc.gnu.org/ml/gcc/2005-06/msg01265.html but that discusses vfork implementation. That's a totally different thing from exec* implementation since the exec* functions have their own stack frames Using alloca() should just require the function using it to use a frame pointer. alloca() allocates simply by subtracting (or adding, depending on your CPU) from the stack pointer. malloc/free _can_ be safe, too _if_ _exactly_ the malloc'ed areas are freed. But how do you call free() after (v)forking? Ugh. I think that's one of those not recommended things. You mean the double-vfrok? I'd consider this to be one of the forbidden things. Yes. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 4/4] NOMMU: Make it possible for RomFS to use MTD devices directly
Andrew Morton [EMAIL PROTECTED] wrote: + brelse(bh); A little fyi: brelse() is rather old-fashioned, and has a usually unneeded test for non-null bh in it. In situations where we know that the pointer is valid, let's please use put_bh(). That's what was in the old romfs. I can make the change, though. Hmmm... brelse() isn't quite equivalent to put_bh(), but the difference seems just to be the message you get if you over-release a buffer head - and the resulting refcount on the BH if that happens. Anyway, I'll assume that dwmw2 will be handling this patch series. I assume so. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 2/4] NOMMU: Add support for direct mapping through mtdconcat if possible
From: David Howells [EMAIL PROTECTED]
Add support for direct mapping through mtdconcat, if possible, by attaching the
samebacking_dev_info structure to the master.
It has some restrictions:
(1) It won't permit direct mapping of concatenated devices that have differing
BDIs.
(2) It doesn't support maps that span the 'gap' between devices, although it
possibly could if the devices spanned across return compatible
(ie. contiguous) addresses from their get_unmapped_area() ops.
Signed-off-by: Gavin Lambert [EMAIL PROTECTED]
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
drivers/mtd/mtdconcat.c | 47 +++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c
index 880580c..730689b 100644
--- a/drivers/mtd/mtdconcat.c
+++ b/drivers/mtd/mtdconcat.c
@@ -15,6 +15,7 @@
#include linux/slab.h
#include linux/sched.h
#include linux/types.h
+#include linux/backing-dev.h
#include linux/mtd/mtd.h
#include linux/mtd/concat.h
@@ -686,6 +687,40 @@ static int concat_block_markbad(struct mtd_info *mtd,
loff_t ofs)
}
/*
+ * try to support NOMMU mmaps on concatenated devices
+ * - we don't support subdev spanning as we can't guarantee it'll work
+ */
+static unsigned long concat_get_unmapped_area(struct mtd_info *mtd,
+ unsigned long len,
+ unsigned long offset,
+ unsigned long flags)
+{
+ struct mtd_concat *concat = CONCAT(mtd);
+ int i;
+
+ for (i = 0; i concat-num_subdev; i++) {
+ struct mtd_info *subdev = concat-subdev[i];
+
+ if (offset = subdev-size) {
+ offset -= subdev-size;
+ continue;
+ }
+
+ /* we've found the subdev over which the mapping will reside */
+ if (offset + len subdev-size)
+ return (unsigned long) -EINVAL;
+
+ if (subdev-get_unmapped_area)
+ return subdev-get_unmapped_area(subdev, len, offset,
+flags);
+
+ break;
+ }
+
+ return (unsigned long) -ENOSYS;
+}
+
+/*
* This function constructs a virtual MTD device by concatenating
* num_devs MTD devices. A pointer to the new device object is
* stored to *new_dev upon success. This function does _not_
@@ -740,6 +775,8 @@ struct mtd_info *mtd_concat_create(struct mtd_info
*subdev[], /* subdevices to c
concat-mtd.ecc_stats.badblocks = subdev[0]-ecc_stats.badblocks;
+ concat-mtd.backing_dev_info = subdev[0]-backing_dev_info;
+
concat-subdev[0] = subdev[0];
for (i = 1; i num_devs; i++) {
@@ -766,6 +803,15 @@ struct mtd_info *mtd_concat_create(struct mtd_info
*subdev[], /* subdevices to c
concat-mtd.flags |=
subdev[i]-flags MTD_WRITEABLE;
}
+
+ /* only permit direct mapping if the BDIs are all the same
+* - copy-mapping is still permitted
+*/
+ if (concat-mtd.backing_dev_info !=
+ subdev[i]-backing_dev_info)
+ concat-mtd.backing_dev_info =
+ default_backing_dev_info;
+
concat-mtd.size += subdev[i]-size;
concat-mtd.ecc_stats.badblocks +=
subdev[i]-ecc_stats.badblocks;
@@ -796,6 +842,7 @@ struct mtd_info *mtd_concat_create(struct mtd_info
*subdev[], /* subdevices to c
concat-mtd.unlock = concat_unlock;
concat-mtd.suspend = concat_suspend;
concat-mtd.resume = concat_resume;
+ concat-mtd.get_unmapped_area = concat_get_unmapped_area;
/*
* Combine the erase block size info of the subdevices:
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
