Prev: [PATCH] x86, smpboot: Fix cores per node printing on boot
Next: mptsas hangs caused by ATA pass-through explained
From: Linus Torvalds on 1 Jun 2010 15:20


On Tue, 1 Jun 2010, David Howells wrote:
>
> From: Mike Frysinger <vapier(a)gentoo.org>
>
> 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.

Umm? The MMU code that we _reverted_?

It turns out to be totally useless, since people put stacks in various
different places, and the values the kernel does see end up not even being
the "real" stack top.

See commit 34441427aab4bdb3069a4ffcda69a99357abcb2e.

Just don't do it.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 4 Jun 2010 17:40
On Tue, 01 Jun 2010 19:59:37 +0100
David Howells <dhowells(a)redhat.com> wrote:

> From: Mike Frysinger <vapier(a)gentoo.org>
>
> 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 00006000 00:01 295 /lib/ld-uClibc.so.0
> 025f0000-025f6f0c r-xs 00000000 00:01 295 /lib/ld-uClibc.so.0
> 02680000-026ba6b0 r-xs 00000000 00:01 297 /lib/libc.so.0
> 02700000-0274d384 r-xs 00000000 00:01 22 /bin/busybox
> 02816000-02817000 rw-p 00000000 00:00 0
> 02848000-0284c0d8 rw-p 00000000 00:00 0
> 02860000-02880000 rw-p 00000000 00:00 0 [stack]
>
> The semi-downside here is that for FLAT, we get:
>
> root:/> cat /proc/155/maps
> 029f0000-029f9000 rwxp 00000000 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.
>

So it's a non-back-compatible change which can a) break nommu-only
userspace and b) unbreak mmu-tested userspace which gets run on nommu.

ho hum, we suck. They can send us the bill.

> --- a/fs/proc/task_nommu.c
> +++ b/fs/proc/task_nommu.c
> @@ -122,11 +122,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, ' ');
> +}

hm, copy-n-paste alert.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH] x86, smpboot: Fix cores per node printing on boot
Next: mptsas hangs caused by ATA pass-through explained