summaryrefslogtreecommitdiffstats
path: root/ipc/util.c
diff options
context:
space:
mode:
authorOleg Nesterov <oleg@redhat.com>2014-10-14 00:54:12 +0200
committerLinus Torvalds <torvalds@linux-foundation.org>2014-10-14 02:18:23 +0200
commitbf77b94c99ad5df0d97a52522fc7a220c0bf44fe (patch)
treefbf5579029160ae086b0ae16ed25ab9814550dbd /ipc/util.c
parentipc: always handle a new value of auto_msgmni (diff)
downloadlinux-bf77b94c99ad5df0d97a52522fc7a220c0bf44fe.tar.xz
linux-bf77b94c99ad5df0d97a52522fc7a220c0bf44fe.zip
ipc/shm: kill the historical/wrong mm->start_stack check
do_shmat() is the only user of ->start_stack (proc just reports its value), and this check looks ugly and wrong. The reason for this check is not clear at all, and it wrongly assumes that the stack can only grow down. But the main problem is that in general mm->start_stack has nothing to do with stack_vma->vm_start. Not only the application can switch to another stack and even unmap this area, setup_arg_pages() expands the stack without updating mm->start_stack during exec(). This means that in the likely case "addr > start_stack - size - PAGE_SIZE * 5" is simply impossible after find_vma_intersection() == F, or the stack can't grow anyway because of RLIMIT_STACK. Many thanks to Hugh for his explanations. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Hugh Dickins <hughd@google.com> Cc: Cyrill Gorcunov <gorcunov@gmail.com> Cc: Davidlohr Bueso <davidlohr.bueso@hp.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'ipc/util.c')
0 files changed, 0 insertions, 0 deletions