From patchwork Thu Apr 27 22:30:24 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Florian Fainelli X-Patchwork-Id: 756172 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3wDWqX6stgz9sCX for ; Fri, 28 Apr 2017 08:30:32 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="bnh/pSxC"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423429AbdD0Wa3 (ORCPT ); Thu, 27 Apr 2017 18:30:29 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:33303 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1162212AbdD0Wa2 (ORCPT ); Thu, 27 Apr 2017 18:30:28 -0400 Received: by mail-it0-f65.google.com with SMTP id z67so3883493itb.0 for ; Thu, 27 Apr 2017 15:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=U/DE3+qINcJlzK1nAiBD0GGeu/z+DqV+lBdeGckULQw=; b=bnh/pSxCmh2vF1b0vgVPp8YLIHCp6VTEJQfCT3c1pLV2dPFY2DXqdJcZf0k1ZVua1G /wYrVBQnC9COm4souCr9ZIIEGmnKLoO+WuZNt32ZsCMiKYNxgtAtEAzTL6yheOiU9rqF 40YEYSNZ0ER8IAhcQPoGtXkB2Htl4BFRlWhdyLu8JkOe1R3Q3KngxZjmZS6kyGb/n4Kb doE4MbmtPsDD5F/lWwwQHfXl+SBk+VmAymDLFzMybRWObIanDhmQAz3SwU8MMsJQhhB1 vHP1Hx/H6xJ+UNibPsFIqKRIsnO+lSckgkKlFPj3WuchsKQfACxmUbsPgFggNKRI6TnG GwFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=U/DE3+qINcJlzK1nAiBD0GGeu/z+DqV+lBdeGckULQw=; b=XWE8OSjT9lTtlHZwH4r63kKJ2zox7oFWxmjJUMG5kinHG2EmcAUVNZco4OFwSP7UvL 2PQRHLTYgMy0V01qsaDOv43RtlL7eQtm/k80ax84JH0vCvaQNuH1gevz045F3F7YWDAJ ZKvfWgMCfK0o4kIG/6VTRkvjlFvVGFDdahXCP7xlp++X80GpJ8VFtVhxFrk96eiqljs4 GcLCFBzcKugVwZeg+FAgGXLC8HMReOC+0VZUGgLBQp36UKnDdEFSsERCYoXjJtroyZar 2JnaAG2gcMGNO5chRGhdl+teGFi+RP2dfUNcfzqD89nZ/31zBhu1r2Jq6dKIaDwVdviM aAag== X-Gm-Message-State: AN3rC/5wbRU2qFUqd9c7syeRXtRccPoSmjSrmbZKOTj33QdVoeIEE440 GeofGzNNCIMlaA== X-Received: by 10.36.94.138 with SMTP id h132mr155807itb.104.1493332227256; Thu, 27 Apr 2017 15:30:27 -0700 (PDT) Received: from stb-bld-03.irv.broadcom.com ([192.19.255.250]) by smtp.gmail.com with ESMTPSA id e97sm297629itd.23.2017.04.27.15.30.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Apr 2017 15:30:26 -0700 (PDT) From: Florian Fainelli To: netdev@vger.kernel.org Cc: davem@davemloft.net, herbert@gondor.apana.org.au, fw@strlen.de, tgraf@suug.ch, Florian Fainelli Subject: [PATCH net-next] rhashtable: Make sure max_size is non zero Date: Thu, 27 Apr 2017 15:30:24 -0700 Message-Id: <20170427223024.32657-1-f.fainelli@gmail.com> X-Mailer: git-send-email 2.12.2 In-Reply-To: <56843a86-9a09-16e8-acec-05a80396f282@gmail.com> References: <56843a86-9a09-16e8-acec-05a80396f282@gmail.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org After commit 6d684e54690c ("rhashtable: Cap total number of entries to 2^31"), we would be hitting a panic() in net/core/rtnetlink.c during initialization. The call stack would look like this: register_pernet_subsys() ... ops->init() rtnetlink_net_init() netlink_kernel_create() netlink_insert() __netlink_insert() rhashtable_lookup_insert_key() __rhashtable_insert_fast() rht_grow_above_max() And here, we have rht_grow_above_max() return true, because ht->nelemts = 0 (legit) && ht->max_elems = 0 (looks bogus). Eventually, we would be return -E2BIG from __rhashtable_insert_fast() and propagate this all the way back to the caller. After commit 6d684e54690c what changed is that we would take the following condition: if (ht->p.max_size < ht->max_elems / 2) ht->max_elems = ht->p.max_size * 2; and since ht->p.max_size = 0, we would set ht->max_elems to 0 as well. Fix this by taking this branch only when ht->p.max_size is non-zero Fixes: Fixes: 6d684e54690c ("rhashtable: Cap total number of entries to 2^31") Signed-off-by: Florian Fainelli --- lib/rhashtable.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/rhashtable.c b/lib/rhashtable.c index 751630bbe409..6b4f07760fec 100644 --- a/lib/rhashtable.c +++ b/lib/rhashtable.c @@ -963,7 +963,7 @@ int rhashtable_init(struct rhashtable *ht, /* Cap total entries at 2^31 to avoid nelems overflow. */ ht->max_elems = 1u << 31; - if (ht->p.max_size < ht->max_elems / 2) + if (ht->p.max_size && (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);