Thread (9 messages) 9 messages, 4 authors, 2016-06-13

Re: [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616

From: Sergey Senozhatsky <hidden>
Date: 2016-06-10 07:25:04
Also in: linux-next, lkml

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.
quoted hunk ↗ jump to hunk
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 <redacted>
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

--
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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help