Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[PATCH 6/6] NOMMU: ramfs: Drop unused local var

2 views
Skip to first unread message

David Howells

unread,
Dec 16, 2009, 7:00:01 PM12/16/09
to
From: Mike Frysinger <vap...@gentoo.org>

Signed-off-by: Mike Frysinger <vap...@gentoo.org>
Signed-off-by: David Howells <dhow...@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;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

David Howells

unread,
Dec 16, 2009, 7:00:02 PM12/16/09
to
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 <dhow...@redhat.com>
Signed-off-by: Mike Frysinger <vap...@gentoo.org>
Cc: Stefani Seibold <ste...@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 */

David Howells

unread,
Dec 16, 2009, 7:00:04 PM12/16/09
to
From: Jie Zhang <jie....@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....@analog.com>


Signed-off-by: Mike Frysinger <vap...@gentoo.org>
Signed-off-by: David Howells <dhow...@redhat.com>

Acked-by: David McCullough <david_mc...@mcafee.com>
Acked-by: Paul Mundt <let...@linux-sh.org>
Acked-by: Greg Ungerer <ge...@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 {

David Howells

unread,
Dec 16, 2009, 7:00:02 PM12/16/09
to
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 <dhow...@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);

Stefani Seibold

unread,
Dec 17, 2009, 2:30:02 AM12/17/09
to
Am Mittwoch, den 16.12.2009, 23:56 +0000 schrieb David Howells:
> 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 <dhow...@redhat.com>
> Signed-off-by: Mike Frysinger <vap...@gentoo.org>
> Cc: Stefani Seibold <ste...@seibold.net>
> Cc: Paul Mundt <let...@linux-sh.org>
> Cc: Robin Getz <rg...@blackfin.uclinux.org>

Acked-by: ste...@seibold.net

David Howells

unread,
Dec 22, 2009, 12:20:02 PM12/22/09
to
From: Mike Frysinger <vap...@gentoo.org>

index c25256a..2917ab1 100644

--

David Howells

unread,
Dec 22, 2009, 12:20:02 PM12/22/09
to
From: Daisuke HATAYAMA <d.hat...@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.hat...@jp.fujitsu.com>
Reviewed-by: Masami Hiramatsu <mhir...@redhat.com>
Acked-by: Paul Mundt <let...@linux-sh.org>


Signed-off-by: David Howells <dhow...@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:

Andrew Morton

unread,
Dec 30, 2009, 5:00:03 PM12/30/09
to

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 ;)

David Howells

unread,
Dec 31, 2009, 6:20:02 AM12/31/09
to
Andrew Morton <ak...@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

0 new messages