From: Andrew Morton <akpm@linux-foundation.org>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org,
Luke Dashjr <luke@dashjr.org>, Ming Lei <ming.lei@canonical.com>,
Johannes Weiner <hannes@cmpxchg.org>,
luke-jr+linuxbugs@utopios.org, dri-devel@lists.freedesktop.org,
Pekka Enberg <penberg@kernel.org>, Mel Gorman <mel@csn.ul.ie>,
David Rientjes <rientjes@google.com>,
Christoph Lameter <cl@linux.com>
Subject: Re: [Bug 87891] New: kernel BUG at mm/slab.c:2625!
Date: Tue, 11 Nov 2014 17:44:12 -0800 [thread overview]
Message-ID: <20141111174412.ba0ac86f.akpm@linux-foundation.org> (raw)
In-Reply-To: <20141112012244.GA21576@js1304-P5Q-DELUXE>
On Wed, 12 Nov 2014 10:22:45 +0900 Joonsoo Kim <iamjoonsoo.kim@lge.com> wrote:
> On Tue, Nov 11, 2014 at 05:02:43PM -0800, Andrew Morton wrote:
> > On Wed, 12 Nov 2014 00:54:01 +0000 Luke Dashjr <luke@dashjr.org> wrote:
> >
> > > On Wednesday, November 12, 2014 12:49:13 AM Andrew Morton wrote:
> > > > But anyway - Luke, please attach your .config to
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=87891?
> > >
> > > Done: https://bugzilla.kernel.org/attachment.cgi?id=157381
> > >
> >
> > OK, thanks. No CONFIG_HIGHMEM of course. I'm stumped.
>
> Hello, Andrew.
>
> I think that the cause is GFP_HIGHMEM.
> GFP_HIGHMEM is always defined regardless CONFIG_HIGHMEM.
> Please look at the do_huge_pmd_anonymous_page().
> It calls alloc_hugepage_vma() and then alloc_pages_vma() is called
> with alloc_hugepage_gfpmask(). This gfpmask includes GFP_TRANSHUGE
> and then GFP_HIGHUSER_MOVABLE.
OK.
So where's the bug? I'm inclined to say that it's in ttm. It's taking
a gfp_mask which means "this is the allocation attempt which we are
attempting to satisfy" and uses that for its own allocation.
But ttm has no business using that gfp_mask for its own allocation
attempt. If anything it should use something like, err,
GFP_KERNEL & ~__GFP_IO & ~__GFP_FS | __GFP_HIGH
although as I mentioned earlier, it would be better to avoid allocation
altogether.
Poor ttm guys - this is a bit of a trap we set for them.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Luke Dashjr <luke@dashjr.org>, Christoph Lameter <cl@linux.com>,
Ming Lei <ming.lei@canonical.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>, Mel Gorman <mel@csn.ul.ie>,
Johannes Weiner <hannes@cmpxchg.org>,
Pauli Nieminen <suokkos@gmail.com>,
Dave Airlie <airlied@linux.ie>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
bugzilla-daemon@bugzilla.kernel.org,
luke-jr+linuxbugs@utopios.org, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org
Subject: Re: [Bug 87891] New: kernel BUG at mm/slab.c:2625!
Date: Tue, 11 Nov 2014 17:44:12 -0800 [thread overview]
Message-ID: <20141111174412.ba0ac86f.akpm@linux-foundation.org> (raw)
In-Reply-To: <20141112012244.GA21576@js1304-P5Q-DELUXE>
On Wed, 12 Nov 2014 10:22:45 +0900 Joonsoo Kim <iamjoonsoo.kim@lge.com> wrote:
> On Tue, Nov 11, 2014 at 05:02:43PM -0800, Andrew Morton wrote:
> > On Wed, 12 Nov 2014 00:54:01 +0000 Luke Dashjr <luke@dashjr.org> wrote:
> >
> > > On Wednesday, November 12, 2014 12:49:13 AM Andrew Morton wrote:
> > > > But anyway - Luke, please attach your .config to
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=87891?
> > >
> > > Done: https://bugzilla.kernel.org/attachment.cgi?id=157381
> > >
> >
> > OK, thanks. No CONFIG_HIGHMEM of course. I'm stumped.
>
> Hello, Andrew.
>
> I think that the cause is GFP_HIGHMEM.
> GFP_HIGHMEM is always defined regardless CONFIG_HIGHMEM.
> Please look at the do_huge_pmd_anonymous_page().
> It calls alloc_hugepage_vma() and then alloc_pages_vma() is called
> with alloc_hugepage_gfpmask(). This gfpmask includes GFP_TRANSHUGE
> and then GFP_HIGHUSER_MOVABLE.
OK.
So where's the bug? I'm inclined to say that it's in ttm. It's taking
a gfp_mask which means "this is the allocation attempt which we are
attempting to satisfy" and uses that for its own allocation.
But ttm has no business using that gfp_mask for its own allocation
attempt. If anything it should use something like, err,
GFP_KERNEL & ~__GFP_IO & ~__GFP_FS | __GFP_HIGH
although as I mentioned earlier, it would be better to avoid allocation
altogether.
Poor ttm guys - this is a bit of a trap we set for them.
--
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>
next prev parent reply other threads:[~2014-11-12 1:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-87891-27@https.bugzilla.kernel.org/>
2014-11-11 23:31 ` [Bug 87891] New: kernel BUG at mm/slab.c:2625! Andrew Morton
2014-11-11 23:31 ` Andrew Morton
2014-11-12 0:36 ` Christoph Lameter
2014-11-12 0:49 ` Andrew Morton
2014-11-12 0:54 ` Luke Dashjr
2014-11-12 1:02 ` Andrew Morton
2014-11-12 1:22 ` Joonsoo Kim
2014-11-12 1:44 ` Andrew Morton [this message]
2014-11-12 1:44 ` Andrew Morton
2014-11-12 2:13 ` Joonsoo Kim
2014-11-12 4:08 ` Tetsuo Handa
2014-11-12 4:38 ` Andrew Morton
2014-11-12 4:38 ` Andrew Morton
2014-11-13 13:43 ` [PATCH] drm/ttm: Avoid memory allocation from shrinker functions Tetsuo Handa
2014-11-12 1:22 ` [Bug 87891] New: kernel BUG at mm/slab.c:2625! Kirill A. Shutemov
2014-11-12 1:47 ` Kirill A. Shutemov
2014-11-12 1:56 ` Andrew Morton
2014-11-12 1:56 ` Andrew Morton
2014-11-12 2:07 ` Kirill A. Shutemov
2014-11-12 2:17 ` Joonsoo Kim
2014-11-12 2:37 ` Kirill A. Shutemov
2014-11-12 8:21 ` Joonsoo Kim
2014-11-12 10:39 ` Mel Gorman
2014-11-13 6:37 ` Joonsoo Kim
2014-11-12 0:44 ` Joonsoo Kim
2014-11-12 0:53 ` Andrew Morton
2014-11-12 0:53 ` Andrew Morton
2014-11-12 1:04 ` Christoph Lameter
2014-11-13 7:04 ` Vlastimil Babka
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=20141111174412.ba0ac86f.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bugzilla-daemon@bugzilla.kernel.org \
--cc=cl@linux.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=luke-jr+linuxbugs@utopios.org \
--cc=luke@dashjr.org \
--cc=mel@csn.ul.ie \
--cc=ming.lei@canonical.com \
--cc=penberg@kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=rientjes@google.com \
/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.