From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@kernel.org>
Cc: linux-next@vger.kernel.org, Michael Holzheu <holzheu@linux.ibm.com>
Subject: [-next 20190118] "kernel BUG at mm/page_alloc.c:3112!"
Date: Mon, 21 Jan 2019 16:43:12 +0100 [thread overview]
Message-ID: <20190121154312.GH4020@osiris> (raw)
Hello,
when running with linux-next from 20190118 we saw the BUG_ON at
mm/page_alloc.c:3112 being hit (see below). This happened on s390
when using the ltp test suite with the 'oom1' test case.
So out-of-memory is certainly expected, a BUG_ON being hit however not.
(note to avoid confusion: the kernel version in the log below contains
the build date, not the linux-next version; however 9673b4aa71ca is
the corresponding linux-next git commit id).
[ 3161.555718] sshd: page allocation failure: order:0, mode:0x400000(GFP_NOWAIT), nodemask=(null),cpuset=/,mems_allowed=0
[ 3161.555721] CPU: 12 PID: 106602 Comm: sshd Not tainted 5.0.0-20190121.rc2.git0.9673b4aa71ca.300.fc29.s390x+next #1
[ 3161.555723] Hardware name: IBM 2964 NC9 712 (LPAR)
[ 3161.555724] Call Trace:
[ 3161.555727] ([<0000000000112e68>] show_stack+0x58/0x70)
[ 3161.555729] [<0000000000a6c4a2>] dump_stack+0x7a/0xa8
[ 3161.555731] [<00000000002c0d5a>] warn_alloc+0xe2/0x178
[ 3161.555734] [<00000000002c1eac>] __alloc_pages_nodemask+0x1024/0x1060
[ 3161.555736] [<000000000033755e>] new_slab+0x476/0x618
[ 3161.555738] [<0000000000339d1e>] ___slab_alloc+0x45e/0x590
[ 3161.555741] [<0000000000339e7c>] __slab_alloc+0x2c/0x48
[ 3161.555743] [<000000000033a07c>] kmem_cache_alloc+0x1e4/0x240
[ 3161.555745] [<0000000000647712>] avc_alloc_node+0x32/0x1c0
[ 3161.555748] [<0000000000647bc2>] avc_compute_av+0x7a/0x208
[ 3161.555750] [<00000000006488f4>] avc_has_perm_noaudit+0xa4/0xf8
[ 3161.555753] [<0000000000665c1a>] security_get_user_sids+0x39a/0x578
[ 3161.555754] [<00000000006551dc>] sel_write_user+0x144/0x250
[ 3161.555757] [<0000000000654e2e>] selinux_transaction_write+0x6e/0xa8
[ 3161.555759] [<0000000000364d10>] __vfs_write+0x38/0x1c0
[ 3161.555761] [<0000000000365068>] vfs_write+0xa0/0x1b0
[ 3161.555762] [<0000000000365322>] ksys_write+0x5a/0xc8
[ 3161.555765] [<0000000000a8c438>] system_call+0xdc/0x2c8
[ 3161.555767] SLUB: Unable to allocate memory on node -1, gfp=0x408000(GFP_NOWAIT|__GFP_ZERO)
[ 3161.555769] cache: avc_node, object size: 72, buffer size: 72, default order: 0, min order: 0
[ 3161.555771] node 0: slabs: 276, objs: 15456, free: 0
[ 3215.347399] ------------[ cut here ]------------
[ 3215.347407] kernel BUG at mm/page_alloc.c:3112!
[ 3215.347507] illegal operation: 0001 ilc:1 [#1] SMP
[ 3215.347511] Modules linked in: loop kvm xt_tcpudp ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ip6table_nat nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat_ipv4 nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nfnetlink ip6table_filter ip6_tables iptable_filter ip_tables x_tables pkey zcrypt rng_core ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha1_s390 eadm_sch sch_fq_codel sha256_s390 sha_common autofs4
[ 3215.347552] CPU: 6 PID: 98 Comm: kcompactd0 Not tainted 5.0.0-20190121.rc2.git0.9673b4aa71ca.300.fc29.s390x+next #1
[ 3215.347554] Hardware name: IBM 2964 NC9 712 (LPAR)
[ 3215.347557] Krnl PSW : 0404d00180000000 00000000002bf182 (__isolate_free_page+0x212/0x218)
[ 3215.347567] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3
[ 3215.347570] Krnl GPRS: 00000000001b8d00 0000000100000080 00000001ffffec38 00000000f0000000
[ 3215.347573] 00000001ffffec40 0000000000176500 0000000000000007 00000001ffffec38
[ 3215.347576] 0000000000000007 00000001ffffe8c0 000003d000000040 000003d000000007
[ 3215.347579] 000003e0038b7dc0 fffffff0c5ffff00 000003e0038b7ae0 000003e0038b7a80
[ 3215.347590] Krnl Code: 00000000002bf172: eb6ff0a80004 lmg %r6,%r15,168(%r15)
00000000002bf178: c0f4003e73ec brcl 15,a8d950
#00000000002bf17e: a7f40001 brc 15,2bf180
>00000000002bf182: 0707 bcr 0,%r7
00000000002bf184: 0707 bcr 0,%r7
00000000002bf186: 0707 bcr 0,%r7
00000000002bf188: c00400000000 brcl 0,2bf188
00000000002bf18e: eb6ff0480024 stmg %r6,%r15,72(%r15)
[ 3215.347638] Call Trace:
[ 3215.347641] ([<000003d085d96000>] 0x3d085d96000)
[ 3215.347645] [<00000000002f0b74>] compaction_alloc+0x394/0x9c8
[ 3215.347649] [<0000000000342d52>] migrate_pages+0x1d2/0xaf0
[ 3215.347652] [<00000000002f29a0>] compact_zone+0x620/0xf20
[ 3215.347654] [<00000000002f3600>] kcompactd_do_work+0x130/0x268
[ 3215.347656] [<00000000002f37d0>] kcompactd+0x98/0x1d0
[ 3215.347661] [<000000000016920c>] kthread+0x144/0x160
[ 3215.347665] [<0000000000a8c652>] kernel_thread_starter+0xa/0x10
[ 3215.347667] [<0000000000a8c648>] kernel_thread_starter+0x0/0x10
[ 3215.347669] Last Breaking-Event-Address:
[ 3215.347671] [<00000000002bf17e>] __isolate_free_page+0x20e/0x218
[ 3215.347674] Kernel panic - not syncing: Fatal exception: panic_on_oops
FWIW, if it helps: the address of the struct page in question is in
register 2 and the memory dump (using 'crash') of it looks like this:
> struct page -x 1ffffec38
struct page {
flags = 0x3d0832bb008,
{
{
lru = {
next = 0x3d084e79008,
prev = 0x1ffffeca8
},
mapping = 0x1ffffec50,
index = 0x1ffffec50,
private = 0x3d0855e3008
},
{
{
slab_list = {
next = 0x3d084e79008,
prev = 0x1ffffeca8
},
{
next = 0x3d084e79008,
pages = 0x1,
pobjects = 0xffffeca8
}
},
slab_cache = 0x1ffffec50,
freelist = 0x1ffffec50,
{
s_mem = 0x3d0855e3008,
counters = 0x3d0855e3008,
{
inuse = 0x0,
objects = 0x1e8,
frozen = 0x0
}
}
},
{
compound_head = 0x3d084e79008,
compound_dtor = 0x0,
compound_order = 0x0,
compound_mapcount = {
counter = 0xffffeca8
}
},
{
_compound_pad_1 = 0x3d084e79008,
_compound_pad_2 = 0x1ffffeca8,
deferred_list = {
next = 0x1ffffec50,
prev = 0x1ffffec50
}
},
{
_pt_pad_1 = 0x3d084e79008,
pmd_huge_pte = 0x1ffffeca8,
_pt_pad_2 = 0x1ffffec50,
{
pt_mm = 0x1ffffec50,
pt_frag_refcount = {
counter = 0x1
}
},
ptl = {
{
rlock = {
raw_lock = {
lock = 0x3d0
}
}
}
}
},
{
pgmap = 0x3d084e79008,
hmm_data = 0x1ffffeca8,
_zd_pad_1 = 0x1ffffec50
},
callback_head = {
next = 0x3d084e79008,
func = 0x1ffffeca8
}
},
{
_mapcount = {
counter = 0x3d0
},
page_type = 0x3d0,
active = 0x3d0,
units = 0x3d0
},
_refcount = {
counter = 0x855e3008
},
mem_cgroup = 0x1ffffec70
}
next reply other threads:[~2019-01-21 15:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-21 15:43 Heiko Carstens [this message]
2019-01-21 16:06 ` [-next 20190118] "kernel BUG at mm/page_alloc.c:3112!" Michal Hocko
2019-01-21 16:37 ` Mel Gorman
2019-01-25 8:03 ` Heiko Carstens
2019-01-25 8:44 ` Mel Gorman
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=20190121154312.GH4020@osiris \
--to=heiko.carstens@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=holzheu@linux.ibm.com \
--cc=linux-mm@kvack.org \
--cc=linux-next@vger.kernel.org \
--cc=mhocko@kernel.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.