linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [0/3] 2.6.35.3 -stable review
@ 2010-08-18 20:31 Greg KH
  2010-08-18 20:30 ` [1/3] mm: fix page table unmap for stack guard page properly Greg KH
                   ` (2 more replies)
  0 siblings, 3 replies; 25+ messages in thread
From: Greg KH @ 2010-08-18 20:31 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: stable-review, torvalds, akpm, alan


This is the start of the stable review cycle for the 2.6.35.3 release.
Yeah, it's a bugfix for the .35.2 kernel, for issues found in that
release.

There are 3 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let us know.  If anyone is a maintainer of the proper subsystem, and
wants to add a Signed-off-by: line to the patch, please respond with it.

Responses should be made by Friday, August 20, 2010 10:00:00 UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.35.3-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h


 Makefile                     |    2 +-
 arch/x86/kernel/cpu/vmware.c |    1 +
 fs/proc/task_mmu.c           |    8 +++++++-
 mm/memory.c                  |   13 ++++++-------
 mm/mlock.c                   |    8 ++++++++
 5 files changed, 23 insertions(+), 9 deletions(-)

^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [2/3] mm: fix up some user-visible effects of the stack guard page
@ 2015-01-05 10:21 Jay Foad
  2015-01-05 21:03 ` Linus Torvalds
  0 siblings, 1 reply; 25+ messages in thread
From: Jay Foad @ 2015-01-05 10:21 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-kernel, stable, stable-review, akpm, alan, Linus Torvalds

Sorry for replying to this old email...

On Wed, 2010-08-18 at 13:30 -0700, Greg KH wrote:
> 2.6.35-stable review patch. If anyone has any objections, please let us know.
>
> ------------------
>
> From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
>
> commit d7824370e26325c881b665350ce64fb0a4fde24a upstream.
>
> This commit makes the stack guard page somewhat less visible to user
> space. It does this by:
>
> - not showing the guard page in /proc/<pid>/maps

> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -210,6 +210,7 @@ static void show_map_vma(struct seq_file *m, struct vm_area_struct *vma)
>   int flags = vma->vm_flags;
>   unsigned long ino = 0;
>   unsigned long long pgoff = 0;
> + unsigned long start;
>   dev_t dev = 0;
>   int len;
>
> @@ -220,8 +221,13 @@ static void show_map_vma(struct seq_file *m, struct vm_area_struct *vma)
>   pgoff = ((loff_t)vma->vm_pgoff) << PAGE_SHIFT;
>   }
>
> + /* We don't show the stack guard page in /proc/maps */
> + start = vma->vm_start;
> + if (vma->vm_flags & VM_GROWSDOWN)
> + start += PAGE_SIZE;
> +
>   seq_printf(m, "%08lx-%08lx %c%c%c%c %08llx %02x:%02x %lu %n",
> - vma->vm_start,
> + start,
>   vma->vm_end,
>   flags & VM_READ ? 'r' : '-',
>   flags & VM_WRITE ? 'w' : '-',

This change seems to be causing a problem with an address sanitizer
(https://code.google.com/p/address-sanitizer/) test case. See here for
some more details: http://reviews.llvm.org/D6777

Address sanitizer tries to find the mapping for the current thread's
stack by iterating through the entries in /proc/self/maps looking for
one that contains the address of some random stack variable. This
fails if the stack mapping has already used up all of its RLIMIT_STACK
quota, because in that case check_stack_guard_page() will fail to add
a guard page, but show_map_vma() will still assume that the first page
of the stack *is* a guard page, and won't report it in /proc/maps.

Here's a small program that demonstrates the failure:

$ cat lim.c
#include <stdio.h>
int main() {
  char a[1000];
  FILE *m = fopen("/proc/self/maps", "r");
  while (fgets(a, sizeof a, m)) {
    unsigned long p = (unsigned long)a, start, end;
    if (sscanf(a, "%lx-%lx", &start, &end) == 2
        && start <= p && p < end) {
      printf("stack found at %lx-%lx\n", start, end);
      goto close;
    }
  }
  printf("stack not found\n");
close:
  fclose(m);
  main();
}

On x86-64 with a 3.16 kernel I get:

$ gcc -o lim lim.c && ulimit -Ss 16 && ./lim
stack found at 7fff389c7000-7fff389ca000
stack found at 7fff389c7000-7fff389ca000
stack found at 7fff389c7000-7fff389ca000
stack not found
stack not found
stack not found
Segmentation fault (core dumped)

This seems like a bug in /proc/maps to me, but is there any chance of
fixing it? Or is it too late to change this behaviour?

Thanks,
Jay.

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2015-01-06 13:27 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-08-18 20:31 [0/3] 2.6.35.3 -stable review Greg KH
2010-08-18 20:30 ` [1/3] mm: fix page table unmap for stack guard page properly Greg KH
2010-08-18 20:30 ` [2/3] mm: fix up some user-visible effects of the stack guard page Greg KH
2010-08-20 12:54   ` Ian Campbell
2010-08-20 15:54     ` Linus Torvalds
2010-08-20 16:02       ` Ian Campbell
2010-08-20 16:07       ` Linus Torvalds
2010-08-20 16:24         ` Linus Torvalds
2010-08-20 17:43           ` Ian Campbell
2010-08-20 18:59             ` Linus Torvalds
2010-08-20 19:43               ` Linus Torvalds
2010-08-20 20:34                 ` [Stable-review] " Willy Tarreau
2010-08-20 20:42                 ` Peter Zijlstra
2010-08-20 21:17                   ` Linus Torvalds
2010-08-20 21:24                     ` Linus Torvalds
2010-08-23  8:58                       ` Peter Zijlstra
2010-08-20 16:32         ` Ian Campbell
2010-08-20 16:35           ` Ian Campbell
2010-08-20 16:49             ` Linus Torvalds
2010-08-18 20:30 ` [3/3] vmware: fix build error in vmware.c Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2015-01-05 10:21 [2/3] mm: fix up some user-visible effects of the stack guard page Jay Foad
2015-01-05 21:03 ` Linus Torvalds
2015-01-05 21:11   ` Linus Torvalds
2015-01-05 21:19   ` Linus Torvalds
2015-01-06 13:27   ` Jay Foad

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).