[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
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
Signed-off-by: David Howells
---
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
RE: [uClinux-dev] Device driver types
> Try the char driver, it is simplest of three. Sounds like a good plan. Thanks for your advice. I'm currently following the ioctl route. It's slightly complicated because my FPGA is effectively a bridge to a number of hot-pluggable backplane I/O cards. It seems to me that I should probably attempt to structure it (the FPGA and backplane) as a bus with I/O card devices hanging off it. The FPGA also performs other functions. So, although I could talk to my FPGA via ioctl commands, how should I talk to the I/O cards when they are plugged in? Should each of these be recognised as a single char device? My other option is to keep it simple and use the driver just to talk to the FPGA and let the application code make sense of the remote I/O cards, for now at least. This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ 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] Device driver types
On Tuesday 22 December 2009 18:11:30 David Wooff wrote: > So, although I could talk to my FPGA via ioctl commands, how should I > talk to the I/O cards > when they are plugged in? Should each of these be recognised as a > single char device? > My other option is to keep it simple and use the driver just to talk to > the FPGA and > let the application code make sense of the remote I/O cards, for now at > least. > Here is the place for your fantasy. At the first glance it seems reasonable to use FPGA driver ioctl's for initializing FPGA and tuning FPGA knobs (signals, registers, whatever) and have another driver for each type of the I/O card, which could be char/block/socket, depending on the nature of the given card. Of course that card driver will use some functions exported by the FPGA driver. -- HTH Vitaly Demyanec ___ 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 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 Signed-off-by: David Howells --- 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 #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(¤t->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
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
Signed-off-by: Mike Frysinger
---
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
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
Reviewed-by: Masami Hiramatsu
Acked-by: Paul Mundt
Signed-off-by: David Howells
---
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
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
Signed-off-by: Mike Frysinger
Signed-off-by: David Howells
Acked-by: David McCullough
Acked-by: Paul Mundt
Acked-by: Greg Ungerer
---
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] Device driver types
On December 22, 2009 11:11:30 am David Wooff wrote: > It's slightly complicated because my FPGA is effectively a bridge to a > number of hot-pluggable > backplane I/O cards. It seems to me that I should probably attempt to > structure it (the FPGA and backplane) > as a bus with I/O card devices hanging off it. The FPGA also performs > other functions. It sounds like ioctls are the way to talk to the FPGA, and your driver should take on the appearance of a platform or multifunction device driver (most likely the latter). I've written drivers like this in the past and it sounds like that's the way you're going to want to head if you want to minimize the amount of code you will be writing. If I were you I think I'd take a look at a few of the MFD drivers (drivers/mfd/*) in the kernel already to get a feel for how things are pieced together, get the FPGA part working and then start building on from there. Basically, as the FPGA detects new card insertions or card removals, the FPGA (base driver) would then use the standard kernel notification system and the kernel would handle all the probing/initialization and/or cleanup of the appropriate sub-driver. These sub-drivers could be either part of the same FPGA driver or even entirely different kernel modules. Each one of them would have its own char device and thus its own ioctls or other interfaces (whichever seems the best fit). udev would take care of userspace notification and the whole system would be pretty flexible and maintainable. -A. ___ 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
