All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: linux-mm@kvack.org, torvalds@linux-foundation.org,
	riel@redhat.com, tbsaunde@tbsaunde.org, robert@ocallahan.org
Subject: Re: [PATCH] mm: check VMA flags to avoid invalid PROT_NONE NUMA balancing
Date: Mon, 26 Sep 2016 09:19:47 +0100	[thread overview]
Message-ID: <20160926081947.GB2838@techsingularity.net> (raw)
In-Reply-To: <20160911225425.10388-1-lstoakes@gmail.com>

On Sun, Sep 11, 2016 at 11:54:25PM +0100, Lorenzo Stoakes wrote:
> The NUMA balancing logic uses an arch-specific PROT_NONE page table flag defined
> by pte_protnone() or pmd_protnone() to mark PTEs or huge page PMDs respectively
> as requiring balancing upon a subsequent page fault. User-defined PROT_NONE
> memory regions which also have this flag set will not normally invoke the NUMA
> balancing code as do_page_fault() will send a segfault to the process before
> handle_mm_fault() is even called.
> 
> However if access_remote_vm() is invoked to access a PROT_NONE region of memory,
> handle_mm_fault() is called via faultin_page() and __get_user_pages() without
> any access checks being performed, meaning the NUMA balancing logic is
> incorrectly invoked on a non-NUMA memory region.
> 
> A simple means of triggering this problem is to access PROT_NONE mmap'd memory
> using /proc/self/mem which reliably results in the NUMA handling functions being
> invoked when CONFIG_NUMA_BALANCING is set.
> 
> This issue was reported in bugzilla (issue 99101) which includes some simple
> repro code.
> 
> There are BUG_ON() checks in do_numa_page() and do_huge_pmd_numa_page() added at
> commit c0e7cad to avoid accidentally provoking strange behaviour by attempting
> to apply NUMA balancing to pages that are in fact PROT_NONE. The BUG_ON()'s are
> consistently triggered by the repro.
> 
> This patch moves the PROT_NONE check into mm/memory.c rather than invoking
> BUG_ON() as faulting in these pages via faultin_page() is a valid reason for
> reaching the NUMA check with the PROT_NONE page table flag set and is therefore
> not always a bug.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=99101
> Reported-by: Trevor Saunders <tbsaunde@tbsaunde.org>
> Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>

Acked-by: Mel Gorman <mgorman@techsingularity.net>

-- 
Mel Gorman
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      parent reply	other threads:[~2016-09-26  8:19 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-11 22:54 [PATCH] mm: check VMA flags to avoid invalid PROT_NONE NUMA balancing Lorenzo Stoakes
2016-09-11 22:59 ` Lorenzo Stoakes
2016-09-11 22:59   ` Lorenzo Stoakes
2016-09-25 18:47 ` Lorenzo Stoakes
2016-09-25 18:47   ` Lorenzo Stoakes
2016-09-25 20:52   ` Linus Torvalds
2016-09-25 20:52     ` Linus Torvalds
2016-09-25 22:24     ` Linus Torvalds
2016-09-25 22:24       ` Linus Torvalds
2016-09-25 22:34     ` Rik van Riel
2016-09-25 22:50       ` Linus Torvalds
2016-09-25 22:50         ` Linus Torvalds
2016-09-25 23:28         ` Hugh Dickins
2016-09-25 23:28           ` Hugh Dickins
2016-09-26  0:49         ` Rik van Riel
2016-09-26  1:05           ` Linus Torvalds
2016-09-26  1:05             ` Linus Torvalds
2016-10-07 10:07         ` Lorenzo Stoakes
2016-10-07 10:07           ` Lorenzo Stoakes
2016-10-07 15:34           ` Linus Torvalds
2016-10-07 15:34             ` Linus Torvalds
2016-10-07 16:22             ` Lorenzo Stoakes
2016-10-07 16:22               ` Lorenzo Stoakes
2016-10-07 18:16               ` Hugh Dickins
2016-10-07 18:16                 ` Hugh Dickins
2016-10-07 18:26                 ` Lorenzo Stoakes
2016-10-07 18:26                   ` Lorenzo Stoakes
2016-10-10  7:47                 ` Jan Kara
2016-10-10  7:47                   ` Jan Kara
2016-10-10  8:28                   ` Lorenzo Stoakes
2016-10-10  8:28                     ` Lorenzo Stoakes
2016-10-10 16:37                     ` Jan Kara
2016-10-10 16:37                       ` Jan Kara
2016-09-26  8:19 ` Mel Gorman [this message]

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=20160926081947.GB2838@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --cc=riel@redhat.com \
    --cc=robert@ocallahan.org \
    --cc=tbsaunde@tbsaunde.org \
    --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.