* arm64: next-20170428 hangs on boot
@ 2017-04-28 13:24 Yury Norov
2017-04-28 14:52 ` Mark Rutland
0 siblings, 1 reply; 6+ messages in thread
From: Yury Norov @ 2017-04-28 13:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
On QEMU the next-20170428 hangs on boot for me due to kernel panic in
rtnetlink_init():
void __init rtnetlink_init(void)
{
if (register_pernet_subsys(&rtnetlink_net_ops))
panic("rtnetlink_init: cannot initialize rtnetlink\n");
...
}
The backtrace is:
#0 arch_counter_get_cntvct () at ./arch/arm64/include/asm/arch_timer.h:160
#1 __delay (cycles=62500) at arch/arm64/lib/delay.c:31
#2 0xffff00000838a430 in __const_udelay (xloops=<optimized out>) at arch/arm64/lib/delay.c:41
#3 0xffff000008165eac in panic (fmt=<optimized out>) at kernel/panic.c:297
#4 0xffff000008b5b9c8 in rtnetlink_init () at net/core/rtnetlink.c:4196
#5 0xffff000008b5be08 in netlink_proto_init () at net/netlink/af_netlink.c:2730
#6 0xffff000008083158 in do_one_initcall (fn=0xffff000008b5bcc4 <netlink_proto_init>) at init/main.c:795
#7 0xffff000008b20d04 in do_initcall_level (level=<optimized out>) at init/main.c:861
#8 do_initcalls () at init/main.c:869
#9 do_basic_setup () at init/main.c:887
#10 kernel_init_freeable () at init/main.c:1039
#11 0xffff000008817bb0 in kernel_init (unused=<optimized out>) at init/main.c:962
#12 0xffff000008082ec0 in ret_from_fork () at arch/arm64/kernel/entry.S:789
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
next-20170426 is OK though.
Yury
^ permalink raw reply [flat|nested] 6+ messages in thread* arm64: next-20170428 hangs on boot 2017-04-28 13:24 arm64: next-20170428 hangs on boot Yury Norov @ 2017-04-28 14:52 ` Mark Rutland 2017-04-28 15:09 ` Yury Norov 2017-04-28 16:05 ` David Miller 0 siblings, 2 replies; 6+ messages in thread From: Mark Rutland @ 2017-04-28 14:52 UTC (permalink / raw) To: linux-arm-kernel On Fri, Apr 28, 2017 at 04:24:29PM +0300, Yury Norov wrote: > Hi all, Hi, [adding Dave Miller, netdev, lkml] > On QEMU the next-20170428 hangs on boot for me due to kernel panic in > rtnetlink_init(): > > void __init rtnetlink_init(void) > { > if (register_pernet_subsys(&rtnetlink_net_ops)) > panic("rtnetlink_init: cannot initialize rtnetlink\n"); > > ... > } I see the same thing with a next-20170428 arm64 defconfig, on a Juno R1 system: [ 0.531949] Kernel panic - not syncing: rtnetlink_init: cannot initialize rtnetlink [ 0.531949] [ 0.541271] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc8-next-20170428-00002-g6ee3799 #10 [ 0.550307] Hardware name: ARM Juno development board (r1) (DT) [ 0.556332] Call trace: [ 0.558833] [<ffff000008088538>] dump_backtrace+0x0/0x238 [ 0.564332] [<ffff000008088834>] show_stack+0x14/0x20 [ 0.569477] [<ffff00000839dd54>] dump_stack+0x9c/0xc0 [ 0.574622] [<ffff000008175344>] panic+0x11c/0x28c [ 0.579505] [<ffff000008d80034>] rtnetlink_init+0x2c/0x1d0 [ 0.585092] [<ffff000008d8047c>] netlink_proto_init+0x14c/0x17c [ 0.591119] [<ffff000008083150>] do_one_initcall+0x38/0x120 [ 0.596796] [<ffff000008d30d00>] kernel_init_freeable+0x1a0/0x240 [ 0.603003] [<ffff00000892a790>] kernel_init+0x10/0x100 [ 0.608324] [<ffff000008082ec0>] ret_from_fork+0x10/0x50 [ 0.613736] SMP: stopping secondary CPUs [ 0.617738] ---[ end Kernel panic - not syncing: rtnetlink_init: cannot initialize rtnetlink If this isn't a known issue, it would be worth trying to bisect this. Thanks, Mark. > The backtrace is: > #0 arch_counter_get_cntvct () at ./arch/arm64/include/asm/arch_timer.h:160 > #1 __delay (cycles=62500) at arch/arm64/lib/delay.c:31 > #2 0xffff00000838a430 in __const_udelay (xloops=<optimized out>) at arch/arm64/lib/delay.c:41 > #3 0xffff000008165eac in panic (fmt=<optimized out>) at kernel/panic.c:297 > #4 0xffff000008b5b9c8 in rtnetlink_init () at net/core/rtnetlink.c:4196 > #5 0xffff000008b5be08 in netlink_proto_init () at net/netlink/af_netlink.c:2730 > #6 0xffff000008083158 in do_one_initcall (fn=0xffff000008b5bcc4 <netlink_proto_init>) at init/main.c:795 > #7 0xffff000008b20d04 in do_initcall_level (level=<optimized out>) at init/main.c:861 > #8 do_initcalls () at init/main.c:869 > #9 do_basic_setup () at init/main.c:887 > #10 kernel_init_freeable () at init/main.c:1039 > #11 0xffff000008817bb0 in kernel_init (unused=<optimized out>) at init/main.c:962 > #12 0xffff000008082ec0 in ret_from_fork () at arch/arm64/kernel/entry.S:789 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > next-20170426 is OK though. > > Yury > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 6+ messages in thread
* arm64: next-20170428 hangs on boot 2017-04-28 14:52 ` Mark Rutland @ 2017-04-28 15:09 ` Yury Norov 2017-04-28 15:40 ` Florian Fainelli 2017-04-28 16:05 ` David Miller 1 sibling, 1 reply; 6+ messages in thread From: Yury Norov @ 2017-04-28 15:09 UTC (permalink / raw) To: linux-arm-kernel On Fri, Apr 28, 2017 at 03:52:34PM +0100, Mark Rutland wrote: > On Fri, Apr 28, 2017 at 04:24:29PM +0300, Yury Norov wrote: > > Hi all, > > Hi, > > [adding Dave Miller, netdev, lkml] thanks > > On QEMU the next-20170428 hangs on boot for me due to kernel panic in > > rtnetlink_init(): > > > > void __init rtnetlink_init(void) > > { > > if (register_pernet_subsys(&rtnetlink_net_ops)) > > panic("rtnetlink_init: cannot initialize rtnetlink\n"); > > > > ... > > } > > I see the same thing with a next-20170428 arm64 defconfig, on a Juno R1 > system: > > [ 0.531949] Kernel panic - not syncing: rtnetlink_init: cannot initialize rtnetlink > [ 0.531949] > [ 0.541271] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc8-next-20170428-00002-g6ee3799 #10 > [ 0.550307] Hardware name: ARM Juno development board (r1) (DT) > [ 0.556332] Call trace: > [ 0.558833] [<ffff000008088538>] dump_backtrace+0x0/0x238 > [ 0.564332] [<ffff000008088834>] show_stack+0x14/0x20 > [ 0.569477] [<ffff00000839dd54>] dump_stack+0x9c/0xc0 > [ 0.574622] [<ffff000008175344>] panic+0x11c/0x28c > [ 0.579505] [<ffff000008d80034>] rtnetlink_init+0x2c/0x1d0 > [ 0.585092] [<ffff000008d8047c>] netlink_proto_init+0x14c/0x17c > [ 0.591119] [<ffff000008083150>] do_one_initcall+0x38/0x120 > [ 0.596796] [<ffff000008d30d00>] kernel_init_freeable+0x1a0/0x240 > [ 0.603003] [<ffff00000892a790>] kernel_init+0x10/0x100 > [ 0.608324] [<ffff000008082ec0>] ret_from_fork+0x10/0x50 > [ 0.613736] SMP: stopping secondary CPUs > [ 0.617738] ---[ end Kernel panic - not syncing: rtnetlink_init: cannot initialize rtnetlink > > If this isn't a known issue, it would be worth trying to bisect this. The exact function that fails is: include/linux/rhashtable.h static inline void *__rhashtable_insert_fast( struct rhashtable *ht, const void *key, struct rhash_head *obj, const struct rhashtable_params params, bool rhlist) { ... data = ERR_PTR(-E2BIG); if (unlikely(rht_grow_above_max(ht, tbl))) goto out; ... out: spin_unlock_bh(lock); rcu_read_unlock(); return data; } And the backtrace: #0 __rhashtable_insert_fast (rhlist=<optimized out>, params=..., obj=<optimized out>, key=<optimized out>, ht=<optimized out>) at ./include/linux/rhashtable.h:803 #1 rhashtable_lookup_insert_key (params=..., obj=<optimized out>, key=<optimized out>, ht=<optimized out>) at ./include/linux/rhashtable.h:980 #2 __netlink_insert (sk=<optimized out>, table=<optimized out>) at net/netlink/af_netlink.c:484 #3 netlink_insert (sk=0xffff80003da85000, portid=0) at net/netlink/af_netlink.c:548 #4 0xffff00000876c5a0 in __netlink_kernel_create (net=<optimized out>, unit=0, module=0x0, cfg=0xffff80003d84fc60) at net/netlink/af_netlink.c:1996 #5 0xffff000008756704 in netlink_kernel_create (cfg=<optimized out>, unit=<optimized out>, net=<optimized out>) at ./include/linux/netlink.h:62 #6 rtnetlink_net_init (net=0xffff000008c7c100 <init_net>) at net/core/rtnetlink.c:4175 #7 0xffff000008737a2c in ops_init (ops=0xffff000008c7e268 <rtnetlink_net_ops>, net=0xffff000008c7c100 <init_net>) at net/core/net_namespace.c:117 #8 0xffff000008738704 in __register_pernet_operations (ops=<optimized out>, list=<optimized out>) at net/core/net_namespace.c:818 #9 register_pernet_operations (list=<optimized out>, ops=0xffff000008c7e268 <rtnetlink_net_ops>) at net/core/net_namespace.c:892 #10 0xffff0000087387fc in register_pernet_subsys (ops=0xffff000008c7e268 <rtnetlink_net_ops>) at net/core/net_namespace.c:934 #11 0xffff000008b5b9b8 in rtnetlink_init () at net/core/rtnetlink.c:4195 #12 0xffff000008b5be08 in netlink_proto_init () at net/netlink/af_netlink.c:2730 #13 0xffff000008083158 in do_one_initcall (fn=0xffff000008b5bcc4 <netlink_proto_init>) at init/main.c:795 #14 0xffff000008b20d04 in do_initcall_level (level=<optimized out>) at init/main.c:861 #15 do_initcalls () at init/main.c:869 #16 do_basic_setup () at init/main.c:887 Yury ^ permalink raw reply [flat|nested] 6+ messages in thread
* arm64: next-20170428 hangs on boot 2017-04-28 15:09 ` Yury Norov @ 2017-04-28 15:40 ` Florian Fainelli 2017-04-28 16:10 ` Yury Norov 0 siblings, 1 reply; 6+ messages in thread From: Florian Fainelli @ 2017-04-28 15:40 UTC (permalink / raw) To: linux-arm-kernel On 04/28/2017 08:09 AM, Yury Norov wrote: > On Fri, Apr 28, 2017 at 03:52:34PM +0100, Mark Rutland wrote: >> On Fri, Apr 28, 2017 at 04:24:29PM +0300, Yury Norov wrote: >>> Hi all, >> >> Hi, >> >> [adding Dave Miller, netdev, lkml] > > thanks > >>> On QEMU the next-20170428 hangs on boot for me due to kernel panic in >>> rtnetlink_init(): >>> >>> void __init rtnetlink_init(void) >>> { >>> if (register_pernet_subsys(&rtnetlink_net_ops)) >>> panic("rtnetlink_init: cannot initialize rtnetlink\n"); >>> >>> ... >>> } >> >> I see the same thing with a next-20170428 arm64 defconfig, on a Juno R1 >> system: >> >> [ 0.531949] Kernel panic - not syncing: rtnetlink_init: cannot initialize rtnetlink >> [ 0.531949] >> [ 0.541271] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc8-next-20170428-00002-g6ee3799 #10 >> [ 0.550307] Hardware name: ARM Juno development board (r1) (DT) >> [ 0.556332] Call trace: >> [ 0.558833] [<ffff000008088538>] dump_backtrace+0x0/0x238 >> [ 0.564332] [<ffff000008088834>] show_stack+0x14/0x20 >> [ 0.569477] [<ffff00000839dd54>] dump_stack+0x9c/0xc0 >> [ 0.574622] [<ffff000008175344>] panic+0x11c/0x28c >> [ 0.579505] [<ffff000008d80034>] rtnetlink_init+0x2c/0x1d0 >> [ 0.585092] [<ffff000008d8047c>] netlink_proto_init+0x14c/0x17c >> [ 0.591119] [<ffff000008083150>] do_one_initcall+0x38/0x120 >> [ 0.596796] [<ffff000008d30d00>] kernel_init_freeable+0x1a0/0x240 >> [ 0.603003] [<ffff00000892a790>] kernel_init+0x10/0x100 >> [ 0.608324] [<ffff000008082ec0>] ret_from_fork+0x10/0x50 >> [ 0.613736] SMP: stopping secondary CPUs >> [ 0.617738] ---[ end Kernel panic - not syncing: rtnetlink_init: cannot initialize rtnetlink >> >> If this isn't a known issue, it would be worth trying to bisect this. It's fixed already by this commit in net-next: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=2d2ab658d2debcb4c0e29c9e6f18e5683f3077bf > > The exact function that fails is: > include/linux/rhashtable.h > static inline void *__rhashtable_insert_fast( > struct rhashtable *ht, const void *key, struct rhash_head *obj, > const struct rhashtable_params params, bool rhlist) > { > ... > > data = ERR_PTR(-E2BIG); > if (unlikely(rht_grow_above_max(ht, tbl))) > goto out; > ... > > out: > spin_unlock_bh(lock); > rcu_read_unlock(); > > return data; > } > > And the backtrace: > #0 __rhashtable_insert_fast (rhlist=<optimized out>, params=..., obj=<optimized out>, > key=<optimized out>, ht=<optimized out>) at ./include/linux/rhashtable.h:803 > #1 rhashtable_lookup_insert_key (params=..., obj=<optimized out>, key=<optimized out>, > ht=<optimized out>) at ./include/linux/rhashtable.h:980 > #2 __netlink_insert (sk=<optimized out>, table=<optimized out>) at net/netlink/af_netlink.c:484 > #3 netlink_insert (sk=0xffff80003da85000, portid=0) at net/netlink/af_netlink.c:548 > #4 0xffff00000876c5a0 in __netlink_kernel_create (net=<optimized out>, unit=0, module=0x0, > cfg=0xffff80003d84fc60) at net/netlink/af_netlink.c:1996 > #5 0xffff000008756704 in netlink_kernel_create (cfg=<optimized out>, unit=<optimized out>, > net=<optimized out>) at ./include/linux/netlink.h:62 > #6 rtnetlink_net_init (net=0xffff000008c7c100 <init_net>) at net/core/rtnetlink.c:4175 > #7 0xffff000008737a2c in ops_init (ops=0xffff000008c7e268 <rtnetlink_net_ops>, > net=0xffff000008c7c100 <init_net>) at net/core/net_namespace.c:117 > #8 0xffff000008738704 in __register_pernet_operations (ops=<optimized out>, > list=<optimized out>) at net/core/net_namespace.c:818 > #9 register_pernet_operations (list=<optimized out>, ops=0xffff000008c7e268 > <rtnetlink_net_ops>) at net/core/net_namespace.c:892 > #10 0xffff0000087387fc in register_pernet_subsys (ops=0xffff000008c7e268 > <rtnetlink_net_ops>) at net/core/net_namespace.c:934 > #11 0xffff000008b5b9b8 in rtnetlink_init () at net/core/rtnetlink.c:4195 > #12 0xffff000008b5be08 in netlink_proto_init () at net/netlink/af_netlink.c:2730 > #13 0xffff000008083158 in do_one_initcall (fn=0xffff000008b5bcc4 <netlink_proto_init>) at init/main.c:795 > #14 0xffff000008b20d04 in do_initcall_level (level=<optimized out>) at init/main.c:861 > #15 do_initcalls () at init/main.c:869 > #16 do_basic_setup () at init/main.c:887 > > Yury > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- Florian ^ permalink raw reply [flat|nested] 6+ messages in thread
* arm64: next-20170428 hangs on boot 2017-04-28 15:40 ` Florian Fainelli @ 2017-04-28 16:10 ` Yury Norov 0 siblings, 0 replies; 6+ messages in thread From: Yury Norov @ 2017-04-28 16:10 UTC (permalink / raw) To: linux-arm-kernel On Fri, Apr 28, 2017 at 08:40:54AM -0700, Florian Fainelli wrote: > On 04/28/2017 08:09 AM, Yury Norov wrote: > > On Fri, Apr 28, 2017 at 03:52:34PM +0100, Mark Rutland wrote: > >> On Fri, Apr 28, 2017 at 04:24:29PM +0300, Yury Norov wrote: > >>> Hi all, > >> > >> Hi, > >> > >> [adding Dave Miller, netdev, lkml] > > > > thanks > > > >>> On QEMU the next-20170428 hangs on boot for me due to kernel panic in > >>> rtnetlink_init(): > >>> > >>> void __init rtnetlink_init(void) > >>> { > >>> if (register_pernet_subsys(&rtnetlink_net_ops)) > >>> panic("rtnetlink_init: cannot initialize rtnetlink\n"); > >>> > >>> ... > >>> } > >> > >> I see the same thing with a next-20170428 arm64 defconfig, on a Juno R1 > >> system: > >> > >> [ 0.531949] Kernel panic - not syncing: rtnetlink_init: cannot initialize rtnetlink > >> [ 0.531949] > >> [ 0.541271] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc8-next-20170428-00002-g6ee3799 #10 > >> [ 0.550307] Hardware name: ARM Juno development board (r1) (DT) > >> [ 0.556332] Call trace: > >> [ 0.558833] [<ffff000008088538>] dump_backtrace+0x0/0x238 > >> [ 0.564332] [<ffff000008088834>] show_stack+0x14/0x20 > >> [ 0.569477] [<ffff00000839dd54>] dump_stack+0x9c/0xc0 > >> [ 0.574622] [<ffff000008175344>] panic+0x11c/0x28c > >> [ 0.579505] [<ffff000008d80034>] rtnetlink_init+0x2c/0x1d0 > >> [ 0.585092] [<ffff000008d8047c>] netlink_proto_init+0x14c/0x17c > >> [ 0.591119] [<ffff000008083150>] do_one_initcall+0x38/0x120 > >> [ 0.596796] [<ffff000008d30d00>] kernel_init_freeable+0x1a0/0x240 > >> [ 0.603003] [<ffff00000892a790>] kernel_init+0x10/0x100 > >> [ 0.608324] [<ffff000008082ec0>] ret_from_fork+0x10/0x50 > >> [ 0.613736] SMP: stopping secondary CPUs > >> [ 0.617738] ---[ end Kernel panic - not syncing: rtnetlink_init: cannot initialize rtnetlink > >> > >> If this isn't a known issue, it would be worth trying to bisect this. > > It's fixed already by this commit in net-next: > > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=2d2ab658d2debcb4c0e29c9e6f18e5683f3077bf Works for me, thank you. ^ permalink raw reply [flat|nested] 6+ messages in thread
* arm64: next-20170428 hangs on boot 2017-04-28 14:52 ` Mark Rutland 2017-04-28 15:09 ` Yury Norov @ 2017-04-28 16:05 ` David Miller 1 sibling, 0 replies; 6+ messages in thread From: David Miller @ 2017-04-28 16:05 UTC (permalink / raw) To: linux-arm-kernel From: Mark Rutland <mark.rutland@arm.com> Date: Fri, 28 Apr 2017 15:52:34 +0100 > On Fri, Apr 28, 2017 at 04:24:29PM +0300, Yury Norov wrote: >> Hi all, > > Hi, > > [adding Dave Miller, netdev, lkml] > >> On QEMU the next-20170428 hangs on boot for me due to kernel panic in >> rtnetlink_init(): >> >> void __init rtnetlink_init(void) >> { >> if (register_pernet_subsys(&rtnetlink_net_ops)) >> panic("rtnetlink_init: cannot initialize rtnetlink\n"); >> >> ... >> } > > I see the same thing with a next-20170428 arm64 defconfig, on a Juno R1 > system: As stated, should be fixed by: >From 2d2ab658d2debcb4c0e29c9e6f18e5683f3077bf Mon Sep 17 00:00:00 2001 From: Herbert Xu <herbert@gondor.apana.org.au> Date: Fri, 28 Apr 2017 14:10:48 +0800 Subject: [PATCH] rhashtable: Do not lower max_elems when max_size is zero The commit 6d684e54690c ("rhashtable: Cap total number of entries to 2^31") breaks rhashtable users that do not set max_size. This is because when max_size is zero max_elems is also incorrectly set to zero instead of 2^31. This patch fixes it by only lowering max_elems when max_size is not zero. Fixes: 6d684e54690c ("rhashtable: Cap total number of entries to 2^31") Reported-by: Florian Fainelli <f.fainelli@gmail.com> Reported-by: kernel test robot <fengguang.wu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> --- lib/rhashtable.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/lib/rhashtable.c b/lib/rhashtable.c index 751630b..3895486 100644 --- a/lib/rhashtable.c +++ b/lib/rhashtable.c @@ -958,13 +958,14 @@ int rhashtable_init(struct rhashtable *ht, if (params->min_size) ht->p.min_size = roundup_pow_of_two(params->min_size); - if (params->max_size) - ht->p.max_size = rounddown_pow_of_two(params->max_size); - /* Cap total entries at 2^31 to avoid nelems overflow. */ ht->max_elems = 1u << 31; - if (ht->p.max_size < ht->max_elems / 2) - ht->max_elems = ht->p.max_size * 2; + + if (params->max_size) { + ht->p.max_size = rounddown_pow_of_two(params->max_size); + if (ht->p.max_size < ht->max_elems / 2) + ht->max_elems = ht->p.max_size * 2; + } ht->p.min_size = max(ht->p.min_size, HASH_MIN_SIZE); -- 2.4.11 ^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-04-28 16:10 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-04-28 13:24 arm64: next-20170428 hangs on boot Yury Norov 2017-04-28 14:52 ` Mark Rutland 2017-04-28 15:09 ` Yury Norov 2017-04-28 15:40 ` Florian Fainelli 2017-04-28 16:10 ` Yury Norov 2017-04-28 16:05 ` David Miller
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).