Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2999047AbdD1QGR (ORCPT ); Fri, 28 Apr 2017 12:06:17 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:55888 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2999000AbdD1QGF (ORCPT ); Fri, 28 Apr 2017 12:06:05 -0400 Date: Fri, 28 Apr 2017 12:06:03 -0400 (EDT) Message-Id: <20170428.120603.1882981347971536826.davem@davemloft.net> To: niklas.cassel@axis.com Cc: herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org Subject: Re: [REGRESSION] boot regression in next-20170428 From: David Miller In-Reply-To: <8138a4bf-30b6-944d-083d-dcee05ce68ba@axis.com> References: <8138a4bf-30b6-944d-083d-dcee05ce68ba@axis.com> 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:39 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2230 Lines: 71 From: Niklas Cassel Date: Fri, 28 Apr 2017 17:08:17 +0200 > Hello > > > Since next-20170428 > the ARTPEC-6 SoC (MACH_ARTPEC6) does no longer boot. > > It works fine with next-20170427. > > > I've bisected it to the following commit: > > 6d684e54690caef45cf14051ddeb7c71beeb681b is the first bad commit > commit 6d684e54690caef45cf14051ddeb7c71beeb681b > Author: Herbert Xu > Date: Thu Apr 27 13:44:51 2017 +0800 > > rhashtable: Cap total number of entries to 2^31 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