Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2998990AbdD1QFp (ORCPT ); Fri, 28 Apr 2017 12:05:45 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:55880 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756789AbdD1QFe (ORCPT ); Fri, 28 Apr 2017 12:05:34 -0400 Date: Fri, 28 Apr 2017 12:05:32 -0400 (EDT) Message-Id: <20170428.120532.2008072008826207366.davem@davemloft.net> To: mark.rutland@arm.com Cc: ynorov@caviumnetworks.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: arm64: next-20170428 hangs on boot From: David Miller In-Reply-To: <20170428145233.GB5292@leverpostej> References: <20170428132429.c3dlxbmt7iqs2isl@yury-N73SV> <20170428145233.GB5292@leverpostej> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 28 Apr 2017 08:24:08 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2309 Lines: 74 From: Mark Rutland 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 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 Reported-by: kernel test robot Signed-off-by: Herbert Xu Signed-off-by: David S. Miller --- 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