Linux-mm Archive on lore.kernel.org
 help / color / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Michal Hocko <mhocko@kernel.org>
Cc: Kyungtae Kim <kt0755@gmail.com>,
	akpm@linux-foundation.org, pavel.tatashin@microsoft.com,
	vbabka@suse.cz, osalvador@suse.de, rppt@linux.vnet.ibm.com,
	aaron.lu@intel.com, iamjoonsoo.kim@lge.com,
	alexander.h.duyck@linux.intel.com, lifeasageek@gmail.com,
	threeearcat@gmail.com, syzkaller@googlegroups.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Subject: Re: UBSAN: Undefined behaviour in mm/page_alloc.c
Date: Fri, 9 Nov 2018 09:56:09 +0000
Message-ID: <20181109095609.GC23260@techsingularity.net> (raw)
In-Reply-To: <20181109084353.GA5321@dhcp22.suse.cz>

On Fri, Nov 09, 2018 at 09:43:53AM +0100, Michal Hocko wrote:
> On Thu 08-11-18 23:09:23, Kyungtae Kim wrote:
> > We report a bug in v4.19-rc2 (4.20-rc1 as well, I guess):
> > 
> > kernel config: https://kt0755.github.io/etc/config_v2-4.19
> > repro: https://kt0755.github.io/etc/repro.c4074.c
> > 
> > In the middle of page request, this arose because order is too large to handle
> >  (mm/page_alloc.c:3119). It actually comes from that order is
> > controllable by user input
> > via raw_cmd_ioctl without its sanity check, thereby causing memory problem.
> > To stop it, we can use like MAX_ORDER for bounds check before using it.
> 
> Yes, we do only check the max order in the slow path. We have already
> discussed something similar with Konstantin [1][2]. Basically kvmalloc
> for a large size might get to the page allocator with an out of bound
> order and warn during direct reclaim.
> 
> I am wondering whether really want to check for the order in the fast
> path instead. I have hard time to imagine this could cause a measurable
> impact.
> 
> The full patch is below
> 
> [1] http://lkml.kernel.org/r/154109387197.925352.10499549042420271600.stgit@buzz
> [2] http://lkml.kernel.org/r/154106356066.887821.4649178319705436373.stgit@buzz
> 

I'm ok with such changes under the policy "there is no point being fast if
we're broken". It's unfortunate and I know the original microoptimisation
was mine but if the fast-path check ends up being a problem then I/we go
back to finding ways of making the page allocator faster from a fundamental
algorithmic point of view and not a microoptimisation approach. There is
potential fruit there, just none that is low-hanging.

-- 
Mel Gorman
SUSE Labs

  parent reply index

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-09  4:09 Kyungtae Kim
2018-11-09  8:42 ` Vlastimil Babka
2018-11-09  8:43 ` Michal Hocko
2018-11-09  9:41   ` Tetsuo Handa
2018-11-09  9:56     ` Michal Hocko
2018-11-09 10:07       ` Tetsuo Handa
2018-11-09 10:25         ` Michal Hocko
2018-11-09 10:10       ` Vlastimil Babka
2018-11-09 10:22         ` Michal Hocko
2018-11-09 10:24         ` Tetsuo Handa
2018-11-09 10:28           ` Michal Hocko
2018-11-09 10:52       ` Balbir Singh
2018-11-09  9:56   ` Mel Gorman [this message]
2018-11-13  9:43   ` Michal Hocko
2018-11-13 23:15     ` Andrew Morton
2018-11-13 23:23       ` Vlastimil Babka
2018-11-13 23:32         ` Andrew Morton
2018-11-14  0:05           ` Vlastimil Babka
2018-11-19 23:57             ` Pavel Machek
2018-11-13 23:29     ` Andrew Morton
2018-11-14  7:10       ` Michal Hocko
2018-11-16 23:43       ` Dmitry Vyukov

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=20181109095609.GC23260@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=aaron.lu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.h.duyck@linux.intel.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=khlebnikov@yandex-team.ru \
    --cc=kt0755@gmail.com \
    --cc=lifeasageek@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=osalvador@suse.de \
    --cc=pavel.tatashin@microsoft.com \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=syzkaller@googlegroups.com \
    --cc=threeearcat@gmail.com \
    --cc=vbabka@suse.cz \
    /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

Linux-mm Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \
		linux-mm@kvack.org
	public-inbox-index linux-mm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kvack.linux-mm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git