All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: lkp@lists.01.org
Subject: Re: [lkp-robot] [mm] 1be7107fbe: kernel_BUG_at_mm/mmap.c
Date: Wed, 21 Jun 2017 22:27:51 +0200	[thread overview]
Message-ID: <20170621202751.GA29638@redhat.com> (raw)
In-Reply-To: <CA+55aFyTRPOuzo2-Q0xM4+D6naGxFtaE_7dbxXOOdwQ4QGPfpw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

On 06/21, Linus Torvalds wrote:
>
> On Wed, Jun 21, 2017 at 12:33 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> > -               if (unlikely(address + 65536 + 32 * sizeof(unsigned long) < regs->sp)) {
> > +if (0)         if (unlikely(address + 65536 + 32 * sizeof(unsigned long) < regs->sp)) {
>
> This smells bad.

Yes.

> That test is not about grow-down or even the guard page. That test is
> that it's always wrong to grow down the stack below %esp.

Sure.

but let me repeat that this test was essentially dismissed when the stack
guard page was introduced. Simply because do_page_pault() never hits (before
the recent patch) this need-to-grow-VM_GROWSDOWN-vma path if the stack grows
by less than PAGE_SIZE.

IOP. Suppose that an application does

	char * p = mmap(MAP_GROWSDOWN);
	for (;;)
		*p-- = 'x';
		

before the "larger stack guard gap, between vmas" change the stack was
enlarged by do_anonymous_page(), __do_page_fault() didn't hit this path.

Now __do_page_fault() tries to expand the stack itself, and this check
fails.

Oleg.


WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Hugh Dickins <hughd@google.com>,
	kernel test robot <xiaolong.ye@intel.com>,
	Michal Hocko <mhocko@suse.com>,
	LKML <linux-kernel@vger.kernel.org>, LKP <lkp@01.org>
Subject: Re: [lkp-robot] [mm] 1be7107fbe: kernel_BUG_at_mm/mmap.c
Date: Wed, 21 Jun 2017 22:27:51 +0200	[thread overview]
Message-ID: <20170621202751.GA29638@redhat.com> (raw)
In-Reply-To: <CA+55aFyTRPOuzo2-Q0xM4+D6naGxFtaE_7dbxXOOdwQ4QGPfpw@mail.gmail.com>

On 06/21, Linus Torvalds wrote:
>
> On Wed, Jun 21, 2017 at 12:33 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> > -               if (unlikely(address + 65536 + 32 * sizeof(unsigned long) < regs->sp)) {
> > +if (0)         if (unlikely(address + 65536 + 32 * sizeof(unsigned long) < regs->sp)) {
>
> This smells bad.

Yes.

> That test is not about grow-down or even the guard page. That test is
> that it's always wrong to grow down the stack below %esp.

Sure.

but let me repeat that this test was essentially dismissed when the stack
guard page was introduced. Simply because do_page_pault() never hits (before
the recent patch) this need-to-grow-VM_GROWSDOWN-vma path if the stack grows
by less than PAGE_SIZE.

IOP. Suppose that an application does

	char * p = mmap(MAP_GROWSDOWN);
	for (;;)
		*p-- = 'x';
		

before the "larger stack guard gap, between vmas" change the stack was
enlarged by do_anonymous_page(), __do_page_fault() didn't hit this path.

Now __do_page_fault() tries to expand the stack itself, and this check
fails.

Oleg.

  reply	other threads:[~2017-06-21 20:27 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-21  2:35 [lkp-robot] [mm] 1be7107fbe: kernel_BUG_at_mm/mmap.c kernel test robot
2017-06-21  2:35 ` kernel test robot
2017-06-21  2:41 ` Hugh Dickins
2017-06-21  2:41   ` Hugh Dickins
2017-06-21 18:29   ` Linus Torvalds
2017-06-21 18:29     ` Linus Torvalds
2017-06-21 19:33     ` Oleg Nesterov
2017-06-21 19:33       ` Oleg Nesterov
2017-06-21 19:39       ` Linus Torvalds
2017-06-21 19:39         ` Linus Torvalds
2017-06-21 20:27         ` Oleg Nesterov [this message]
2017-06-21 20:27           ` Oleg Nesterov
2017-06-21 20:30           ` Linus Torvalds
2017-06-21 20:30             ` Linus Torvalds
2017-06-21 20:56             ` Oleg Nesterov
2017-06-21 20:56               ` Oleg Nesterov
2017-06-21 22:19               ` Linus Torvalds
2017-06-21 22:19                 ` Linus Torvalds
2017-06-22  1:07                 ` Hugh Dickins
2017-06-22  1:07                   ` Hugh Dickins
2017-06-22 10:58                   ` Dmitry Safonov
2017-06-22 10:58                     ` Dmitry Safonov
2017-06-22 15:16                   ` Oleg Nesterov
2017-06-22 15:16                     ` Oleg Nesterov
2017-06-22 18:04                     ` Hugh Dickins
2017-06-22 18:04                       ` Hugh Dickins
2017-06-22 20:51                       ` Oleg Nesterov
2017-06-22 20:51                         ` Oleg Nesterov
2017-06-22  4:23       ` Hugh Dickins
2017-06-22  4:23         ` Hugh Dickins
2017-06-21 19:39     ` Hugh Dickins
2017-06-21 19:39       ` Hugh Dickins

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=20170621202751.GA29638@redhat.com \
    --to=oleg@redhat.com \
    --cc=lkp@lists.01.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.