From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-next@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash
Date: Wed, 27 Jul 2016 09:14:00 +0200 [thread overview]
Message-ID: <20160727071400.GA3912@osiris> (raw)
Hi Ted,
it looks like your patch "random: make /dev/urandom scalable for silly
userspace programs" within linux-next seems to be a bit broken:
It causes this allocation failure and subsequent crash on s390 with fake
NUMA enabled:
[ 0.533195] SLUB: Unable to allocate memory on node 1, gfp=0x24008c0(GFP_KERNEL|__GFP_NOFAIL)
[ 0.533198] cache: kmalloc-192, object size: 192, buffer size: 528, defaul order: 3, min order: 0
[ 0.533202] node 0: slabs: 2, objs: 124, free: 17
[ 0.533208] Unable to handle kernel pointer dereference in virtual kernel address space
[ 0.533211] Failing address: 0000000000000000 TEID: 0000000000000483
...
[ 0.533276] Krnl PSW : 0704e00180000000 00000000001a853e (lockdep_init_map+0x1e/0x220)
[ 0.533281] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
Krnl GPRS: 0000000000a23400 00000000370c8008 0000000000000060 0000000000bedc90
[ 0.533285] 0000000002070800 0000000000000000 0000000000000001 0000000000000000
[ 0.533287] 000000003743d3f8 000000003743d408 0000000002070800 0000000000bedc90
[ 0.533289] 0000000000000048 00000000009c2030 00000000370cfd00 00000000370cfcc0
[ 0.533295] Krnl Code: 00000000001a852e: a7840001 brc 8,1a8530
00000000001a8532: e3f0ffc0ff71 lay %r15,-64(%r15)
#00000000001a8538: e3e0f0980024 stg %r14,152(%r15)
>00000000001a853e: e54820080000 mvghi 8(%r2),0
00000000001a8544: e54820100000 mvghi 16(%r2),0
00000000001a854a: 58100370 l %r1,880
00000000001a854e: 50102020 st %r1,32(%r2)
00000000001a8552: b90400c2 lgr %r12,%r2
[ 0.533313] Call Trace:
[ 0.533315] ([<0000000000000001>] 0x1)
[ 0.533318] ([<00000000001b4220>] __raw_spin_lock_init+0x50/0x80)
[ 0.533320] ([<0000000000759e7a>] rand_initialize+0xc2/0xf0)
[ 0.533322] ([<00000000001002cc>] do_one_initcall+0xb4/0x140)
[ 0.533325] ([<0000000000ef2cc0>] kernel_init_freeable+0x140/0x2d8)
[ 0.533328] ([<00000000009b07ea>] kernel_init+0x2a/0x150)
[ 0.533330] ([<00000000009bd782>] kernel_thread_starter+0x6/0xc)
[ 0.533332] ([<00000000009bd77c>] kernel_thread_starter+0x0/0xc)
To me it looks rand_initialize is broken with CONFIG_NUMA:
static int rand_initialize(void)
{
#ifdef CONFIG_NUMA
int i;
int num_nodes = num_possible_nodes();
struct crng_state *crng;
struct crng_state **pool;
#endif
init_std_data(&input_pool);
init_std_data(&blocking_pool);
crng_initialize(&primary_crng);
#ifdef CONFIG_NUMA
pool = kmalloc(num_nodes * sizeof(void *),
GFP_KERNEL|__GFP_NOFAIL|__GFP_ZERO);
for (i=0; i < num_nodes; i++) {
crng = kmalloc_node(sizeof(struct crng_state),
GFP_KERNEL | __GFP_NOFAIL, i);
spin_lock_init(&crng->lock);
crng_initialize(crng);
pool[i] = crng;
}
mb();
crng_node_pool = pool;
#endif
return 0;
}
early_initcall(rand_initialize);
First the for loop should use for_each_node() to skip not possible nodes,
no?
However that wouldn't be enough, since in this case it crashed because node
1 is in the possible map, but it isn't online and doesn't have any memory,
which explains why the allocation fails and the subsequent crash when
calling spin_lock_init().
I think the proper fix would be to simply use for_each_online_node(); at
least that fixes the crash on s390.
WARNING: multiple messages have this Message-ID (diff)
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-next@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash
Date: Wed, 27 Jul 2016 09:14:00 +0200 [thread overview]
Message-ID: <20160727071400.GA3912@osiris> (raw)
Hi Ted,
it looks like your patch "random: make /dev/urandom scalable for silly
userspace programs" within linux-next seems to be a bit broken:
It causes this allocation failure and subsequent crash on s390 with fake
NUMA enabled:
[ 0.533195] SLUB: Unable to allocate memory on node 1, gfp=0x24008c0(GFP_KERNEL|__GFP_NOFAIL)
[ 0.533198] cache: kmalloc-192, object size: 192, buffer size: 528, defaul order: 3, min order: 0
[ 0.533202] node 0: slabs: 2, objs: 124, free: 17
[ 0.533208] Unable to handle kernel pointer dereference in virtual kernel address space
[ 0.533211] Failing address: 0000000000000000 TEID: 0000000000000483
...
[ 0.533276] Krnl PSW : 0704e00180000000 00000000001a853e (lockdep_init_map+0x1e/0x220)
[ 0.533281] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
Krnl GPRS: 0000000000a23400 00000000370c8008 0000000000000060 0000000000bedc90
[ 0.533285] 0000000002070800 0000000000000000 0000000000000001 0000000000000000
[ 0.533287] 000000003743d3f8 000000003743d408 0000000002070800 0000000000bedc90
[ 0.533289] 0000000000000048 00000000009c2030 00000000370cfd00 00000000370cfcc0
[ 0.533295] Krnl Code: 00000000001a852e: a7840001 brc 8,1a8530
00000000001a8532: e3f0ffc0ff71 lay %r15,-64(%r15)
#00000000001a8538: e3e0f0980024 stg %r14,152(%r15)
>00000000001a853e: e54820080000 mvghi 8(%r2),0
00000000001a8544: e54820100000 mvghi 16(%r2),0
00000000001a854a: 58100370 l %r1,880
00000000001a854e: 50102020 st %r1,32(%r2)
00000000001a8552: b90400c2 lgr %r12,%r2
[ 0.533313] Call Trace:
[ 0.533315] ([<0000000000000001>] 0x1)
[ 0.533318] ([<00000000001b4220>] __raw_spin_lock_init+0x50/0x80)
[ 0.533320] ([<0000000000759e7a>] rand_initialize+0xc2/0xf0)
[ 0.533322] ([<00000000001002cc>] do_one_initcall+0xb4/0x140)
[ 0.533325] ([<0000000000ef2cc0>] kernel_init_freeable+0x140/0x2d8)
[ 0.533328] ([<00000000009b07ea>] kernel_init+0x2a/0x150)
[ 0.533330] ([<00000000009bd782>] kernel_thread_starter+0x6/0xc)
[ 0.533332] ([<00000000009bd77c>] kernel_thread_starter+0x0/0xc)
To me it looks rand_initialize is broken with CONFIG_NUMA:
static int rand_initialize(void)
{
#ifdef CONFIG_NUMA
int i;
int num_nodes = num_possible_nodes();
struct crng_state *crng;
struct crng_state **pool;
#endif
init_std_data(&input_pool);
init_std_data(&blocking_pool);
crng_initialize(&primary_crng);
#ifdef CONFIG_NUMA
pool = kmalloc(num_nodes * sizeof(void *),
GFP_KERNEL|__GFP_NOFAIL|__GFP_ZERO);
for (i=0; i < num_nodes; i++) {
crng = kmalloc_node(sizeof(struct crng_state),
GFP_KERNEL | __GFP_NOFAIL, i);
spin_lock_init(&crng->lock);
crng_initialize(crng);
pool[i] = crng;
}
mb();
crng_node_pool = pool;
#endif
return 0;
}
early_initcall(rand_initialize);
First the for loop should use for_each_node() to skip not possible nodes,
no?
However that wouldn't be enough, since in this case it crashed because node
1 is in the possible map, but it isn't online and doesn't have any memory,
which explains why the allocation fails and the subsequent crash when
calling spin_lock_init().
I think the proper fix would be to simply use for_each_online_node(); at
least that fixes the crash on s390.
--
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 reply other threads:[~2016-07-27 7:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-27 7:14 Heiko Carstens [this message]
2016-07-27 7:14 ` [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash Heiko Carstens
2016-07-28 3:46 ` Theodore Ts'o
2016-07-28 3:46 ` Theodore Ts'o
2016-07-28 5:55 ` Heiko Carstens
2016-07-28 5:55 ` Heiko Carstens
2016-07-28 7:24 ` Heiko Carstens
2016-07-28 7:24 ` Heiko Carstens
2016-07-28 13:41 ` Theodore Ts'o
2016-07-28 13:41 ` Theodore Ts'o
2016-07-28 23:56 ` Tony Luck
2016-07-28 23:56 ` Tony Luck
2016-07-28 18:12 ` Joe Perches
2016-07-28 18:12 ` Joe Perches
2016-07-28 18:12 ` Joe Perches
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=20160727071400.GA3912@osiris \
--to=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-next@vger.kernel.org \
--cc=schwidefsky@de.ibm.com \
--cc=tytso@mit.edu \
/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.