All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Larry Woodman <lwoodman@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Michal Hocko <mhocko@suse.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH 0/1] expand_downwards: don't require the gap if !vm_prev
Date: Wed, 28 Jun 2017 19:52:37 +0200	[thread overview]
Message-ID: <20170628175237.GA24868@redhat.com> (raw)

See the patch, but actually I have another question...

Now that the stack-guard-page has gone, why do we need to allow to grow
into the previous VM_GROWSDOWN vma? IOW, why we can not simply remove
the VM_GROWSDOWN check in expand_downwards() ?

Yes, this is what the kernel did before the recent changes. But afaics
only because the kernel could not know if the vma->vm_start page is
actually guard or not.

IOW, iiuc before the recent change it was not simple to _disallow_ this,
and that is why it worked. Just for example, suppose an application does

	addr = mmap(MAP_GROWSDOWN);
	mprotect(addr, PAGE_SIZE, PROT_NONE);
	*(addr + PAGE_SIZE) = 0;

and of course this should not fail.

But the the kernel could not know if vm_start == addr + PAGE_SIZE is the
"valid" address, or this vma was expanded before and vm_start is the stack
guard.

Yes, we can probably check anon_vma's as the comment suggests, but imo we
we can just remove the VM_GROWSDOWN case unconditionally.

Oleg.

             reply	other threads:[~2017-06-28 17:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-28 17:52 Oleg Nesterov [this message]
2017-06-28 17:52 ` [PATCH 1/1] expand_downwards: don't require the gap if !vm_prev Oleg Nesterov
2017-06-30 13:16   ` Michal Hocko
2017-06-28 23:26 ` [PATCH 0/1] " Linus Torvalds
2017-06-29 15:19   ` Oleg Nesterov
2017-06-29 18:21     ` Linus Torvalds
2017-06-29 18:55       ` Oleg Nesterov
2017-06-29 19:00         ` Linus Torvalds
2017-06-30 13:24   ` Michal Hocko
2017-06-30 17:08     ` Linus Torvalds
2017-06-30 17:26       ` Michal Hocko
2017-06-30 17:48         ` Linus Torvalds
2017-07-03 15:49           ` Michal Hocko
2017-07-03 16:30             ` Linus Torvalds
2017-07-03 16:54               ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170628175237.GA24868@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lwoodman@redhat.com \
    --cc=mhocko@suse.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.