From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Stephen Rothwell <sfr@canb.auug.org.au>,
linux-mm@kvack.org, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616
Date: Fri, 10 Jun 2016 16:24:59 +0900 [thread overview]
Message-ID: <20160610072459.GA585@swordfish> (raw)
In-Reply-To: <20160610063419.GB32285@dhcp22.suse.cz>
that was fast!
On (06/10/16 08:34), Michal Hocko wrote:
[..]
> OK, so this is flags & GFP_SLAB_BUG_MASK BUG_ON because gfp is
> ___GFP_HIGHMEM. It is my [1] patch which has introduced it.
> I think we need the following. Andrew could you fold it into
> mm-memcg-use-consistent-gfp-flags-during-readahead.patch or maybe keep
> it as a separate patch?
>
> [1] http://lkml.kernel.org/r/1465301556-26431-1-git-send-email-mhocko@kernel.org
>
> Thanks for the report Sergey!
after quick tests -- works for me. please see below.
> Sergey has reported that we might hit BUG_ON in new_slab() because
> unrestricted gfp mask used for the readahead purposes contains
> incompatible flags (__GFP_HIGHMEM in his case):
> [ 429.191962] gfp: 2
> [ 429.192634] ------------[ cut here ]------------
> [ 429.193281] kernel BUG at mm/slub.c:1616!
> [...]
> [ 429.217369] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
> [ 429.218013] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
> [ 429.218650] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
> [ 429.219282] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
>
> Make sure that mpage_alloc always restricts the mask GFP_KERNEL subset.
> This is what was done before "mm, memcg: use consistent gfp flags during
> readahead" explicitly by mapping_gfp_constraint(mapping, GFP_KERNEL) in
> mpage_readpages.
>
> Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> fs/mpage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/mpage.c b/fs/mpage.c
> index 9c11255b0797..5ce75b2e60d1 100644
> --- a/fs/mpage.c
> +++ b/fs/mpage.c
> @@ -71,7 +71,7 @@ mpage_alloc(struct block_device *bdev,
> {
> struct bio *bio;
>
> - bio = bio_alloc(gfp_flags, nr_vecs);
> + bio = bio_alloc(gfp_flags & GFP_KERNEL, nr_vecs);
>
> if (bio == NULL && (current->flags & PF_MEMALLOC)) {
> while (!bio && (nr_vecs /= 2))
so the first bio_alloc() is ok now. what about the second bio_alloc()
in mpage_alloc()? it'll still see the ___GFP_HIGHMEM?
may be something like this (composed in mail client)
static struct bio *
mpage_alloc(struct block_device *bdev,
sector_t first_sector, int nr_vecs,
gfp_t gfp_flags)
{
struct bio *bio;
+ gfp_flags &= GFP_KERNEL;
- bio = bio_alloc(gfp_flags, nr_vecs);
+ bio = bio_alloc(gfp_flags & GFP_KERNEL, nr_vecs);
if (bio == NULL && (current->flags & PF_MEMALLOC)) {
while (!bio && (nr_vecs /= 2))
bio = bio_alloc(gfp_flags, nr_vecs);
^^^^^^^^^^^^^^^^^^^^ BUG?
}
if (bio) {
bio->bi_bdev = bdev;
bio->bi_iter.bi_sector = first_sector;
}
return bio;
}
=====
the second part of the original report (sleeping function called from
invalid context at include/linux/sched.h:2960) is unrelated, I'll fork
a new thread; seems that it's coming from a380a3c755, Christoph Lameter,
2015-11-20.
-ss
next prev parent reply other threads:[~2016-06-10 7:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-10 6:11 [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616 Sergey Senozhatsky
2016-06-10 6:34 ` Michal Hocko
2016-06-10 7:24 ` Sergey Senozhatsky [this message]
2016-06-10 7:42 ` Michal Hocko
2016-06-10 9:50 ` [mmots-2016-06-09-16-49] sleeping function called from slab_alloc() Sergey Senozhatsky
2016-06-10 9:55 ` mhocko
2016-06-10 9:58 ` Sergey Senozhatsky
2016-06-10 21:59 ` Andrew Morton
2016-06-13 10:47 ` 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=20160610072459.GA585@swordfish \
--to=sergey.senozhatsky.work@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-next@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=sfr@canb.auug.org.au \
--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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).