Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp1583545rwb; Fri, 13 Jan 2023 14:32:42 -0800 (PST) X-Google-Smtp-Source: AMrXdXsero877KoGWsYzDFBPNTSGXXHEzx0acKubB3YwxMZaEe9Z05IPuEOlGnB8DGsE5EeiQyv0 X-Received: by 2002:a05:6402:1d98:b0:498:b9ea:1894 with SMTP id dk24-20020a0564021d9800b00498b9ea1894mr19708061edb.15.1673649162368; Fri, 13 Jan 2023 14:32:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673649162; cv=none; d=google.com; s=arc-20160816; b=U32Ujh5Aic+zkyGbttgmopuegCpzE6pBqD2r14CakO2MAyZLR9ZSm0bGzZRtvdkq1L ovk9Ky2yFgOm4FWgg4mVTY870DPMuY+gW8uemDJhu/0lXYBycTIUFGX0wY72gaa9ekBS DlTbC8niOmTJMOpJD8XvyzBNTUnQc3N2w3bw7zVGtDioafprxByZ1zCBCUW1HhVkhLEL BGQCe69DtcwL735NZO1Z4dRSNXuPDwavNrrIjwtorNLEQLw66e72K3qNnVyZZHqnrkcj gCI8qokX2YfmV9QTWU6Jgn9KiT5TDVd9HMum1Lw9D3+Ighf30+At3Wnjzlu7F9KT25b0 ttMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=g9fyweIDEPmWr/lZahgcMURtuZX9znfqDKeRUR/Vg14=; b=CF7v3t6vHfY4V+cGypn2Re2hx6S7ZI+/y3jsBsZ4N3a2N6sI7QZdY/+eoX760BzYbu XAVpay1QO9Bu+2is8gew7C/Sw4FoP49DjRW9P6Avnb5OAkszkxlvzJq4TwU7iMpjiSuA Uu/F5L/pb2FVptoW3IlypfsAdD6NM1GK3JmIyUVfLFjkWDMTRWGfsrFW/GR2S2Vl1EpW 41VhlSbwHLVScqCQksUwhNMvqE46E/CLuslqb6YIFkRY9VQiCUSCdRn9RSIJN0LifcEb zQinrdb7tOeHerhwqLpIZdJPt1cGlRkOU3KLLf+SfRcUc0FB130vbXWfFZIMAVT/13tz 5rbw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Izd0QFv5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b13-20020a056402278d00b0047010e04c4dsi26831706ede.481.2023.01.13.14.32.29; Fri, 13 Jan 2023 14:32:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Izd0QFv5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229505AbjAMWX0 (ORCPT + 52 others); Fri, 13 Jan 2023 17:23:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34642 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229889AbjAMWXY (ORCPT ); Fri, 13 Jan 2023 17:23:24 -0500 Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com [IPv6:2001:4860:4864:20::2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B209B777C3 for ; Fri, 13 Jan 2023 14:23:22 -0800 (PST) Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-15ed38a9b04so5155139fac.8 for ; Fri, 13 Jan 2023 14:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=g9fyweIDEPmWr/lZahgcMURtuZX9znfqDKeRUR/Vg14=; b=Izd0QFv5zZ4sNOIJRLqu8TUyfJNoOFrulZQmLf0Z8Ejglu1M+YQTs8GnWsq44/lXrK a3HLnlL8JxuiX47indm2TNCcV9+e7iRVrp6En977dv0eaH5LnKie3uwq3UIl2ZUTcj93 X8eaCRONY9+VKJkXz2/FRi8gDH0qkrHbhN1XvfnJJdzKb5zN1BDajULoHPtCrZQ8DNDK /plqEO7CX/CJy9HdLB4G8rqiGKAKX7u0Fd9pwC4Q82lfRVo25dhi6I++7POQ12xZbrsn f9PboYI2h2Nns267/og7GqoBz5TKH2I/nZzyR94YxYgrYsBHneJ4uzXQ2Cd8WO8wgOmN d7Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=g9fyweIDEPmWr/lZahgcMURtuZX9znfqDKeRUR/Vg14=; b=LcnXceKx/NBScVEg+FWAj/PZta7JLRB9w0PPMGNK9MKrEzLKFHvBTGloFOmtpsUSHO egA5mxm+ZJIhOZ8QSDKlFGqaikk/9+3LE9TBaoqjdzUS3xaTdFoXqS841UxhusAue2Fq 36Bv23MjyOAM4A2CFjgC2aTcuOikIfSu8no4+gs7yZgU2oYLGIEBPs5+HU2RtUKQKoyi Td+8KAsw2O99VVygz6Re4cIeAO7ZNaPJcrg20eBWMhw5QhDFSt0qqAILp1tLv9hfHkPL tkqi1UJVWA7dW60ODw6upOCp2eW2hDiezN6cnFTsgt4WaVoQCUxvDEdCBFEl6tPm/2wV Rr2Q== X-Gm-Message-State: AFqh2kqSlLhPpm/5ggU4zms0D4MVz+vsseZvjLfxpy/i7+VxopdFyg18 Neca0T+QY2kd0hnJh/kxBJBI6dyJTKGS5IJDjUY2RQ== X-Received: by 2002:a05:6870:c90e:b0:15b:b80c:e3bd with SMTP id hj14-20020a056870c90e00b0015bb80ce3bdmr1035163oab.273.1673648601546; Fri, 13 Jan 2023 14:23:21 -0800 (PST) MIME-Version: 1.0 References: <20221220031023.197178-1-rmoar@google.com> In-Reply-To: From: Rae Moar Date: Fri, 13 Jan 2023 17:23:10 -0500 Message-ID: Subject: Re: [PATCH v1] lib/hashtable_test.c: add test for the hashtable structure To: Daniel Latypov Cc: brendanhiggins@google.com, davidgow@google.com, skhan@linuxfoundation.org, kunit-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 27, 2022 at 9:00 PM Daniel Latypov wrote: > > On Mon, Dec 19, 2022 at 7:16 PM Rae Moar wrote: > > > > Add a KUnit test for the kernel hashtable implementation in > > include/linux/hashtable.h. > > > > Note that this version does not yet test each of the rcu > > alternative versions of functions. > > > > Signed-off-by: Rae Moar > > Looks pretty good from a cursory glance. > Had some mostly stylistic nits/suggestions below. > > > --- > > > > Note: The check patch script is outputting open brace errors on lines > > 154, 186, 231 of lib/hashtable_test.c but I believe the format of the > > braces on those lines is consistent with the Linux Kernel style guide. > > Will continue to look at these errors. > > > > lib/Kconfig.debug | 13 ++ > > lib/Makefile | 1 + > > lib/hashtable_test.c | 299 +++++++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 313 insertions(+) > > create mode 100644 lib/hashtable_test.c > > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > index 3fc7abffc7aa..3cf3b6f8cff4 100644 > > --- a/lib/Kconfig.debug > > +++ b/lib/Kconfig.debug > > @@ -2458,6 +2458,19 @@ config LIST_KUNIT_TEST > > > > If unsure, say N. > > > > +config HASHTABLE_KUNIT_TEST > > + tristate "KUnit Test for Kernel Hashtable structures" if !KUNIT_ALL_TESTS > > + depends on KUNIT > > + default KUNIT_ALL_TESTS > > + help > > + This builds the hashtable KUnit test suite. > > + It tests the API and basic functionality of the functions > > + and associated macros defined in include/linux/hashtable.h. > > nit: the "functions and associated macros" == "the API", so perhaps we > can shorten this a bit. This seems better to me. Thanks! > > > + For more information on KUnit and unit tests in general please refer > > + to the KUnit documentation in Documentation/dev-tools/kunit/. > > + > > + If unsure, say N. > > + > > config LINEAR_RANGES_TEST > > tristate "KUnit test for linear_ranges" > > depends on KUNIT > > diff --git a/lib/Makefile b/lib/Makefile > > index 161d6a724ff7..9036d3aeee0a 100644 > > --- a/lib/Makefile > > +++ b/lib/Makefile > > @@ -370,6 +370,7 @@ obj-$(CONFIG_PLDMFW) += pldmfw/ > > CFLAGS_bitfield_kunit.o := $(DISABLE_STRUCTLEAK_PLUGIN) > > obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o > > obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o > > +obj-$(CONFIG_HASHTABLE_KUNIT_TEST) += hashtable_test.o > > obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o > > obj-$(CONFIG_BITS_TEST) += test_bits.o > > obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o > > diff --git a/lib/hashtable_test.c b/lib/hashtable_test.c > > new file mode 100644 > > index 000000000000..7907df66a8e7 > > --- /dev/null > > +++ b/lib/hashtable_test.c > > @@ -0,0 +1,299 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * KUnit test for the Kernel Hashtable structures. > > + * > > + * Copyright (C) 2022, Google LLC. > > + * Author: Rae Moar > > + */ > > +#include > > + > > +#include > > + > > +struct hashtable_test_entry { > > + int key; > > + int data; > > + struct hlist_node node; > > + int visited; > > +}; > > + > > +static void hashtable_test_hash_init(struct kunit *test) > > +{ > > + /* Test the different ways of initialising a hashtable. */ > > + DEFINE_HASHTABLE(hash1, 3); > > + DECLARE_HASHTABLE(hash2, 3); > > + > > + hash_init(hash1); > > + hash_init(hash2); > > + > > + KUNIT_EXPECT_TRUE(test, hash_empty(hash1)); > > + KUNIT_EXPECT_TRUE(test, hash_empty(hash2)); > > +} > > + > > +static void hashtable_test_hash_empty(struct kunit *test) > > +{ > > + struct hashtable_test_entry a; > > + DEFINE_HASHTABLE(hash, 3); > > + > > + hash_init(hash); > > + KUNIT_EXPECT_TRUE(test, hash_empty(hash)); > > + > > + a.key = 1; > > + a.data = 13; > > + hash_add(hash, &a.node, a.key); > > + > > + /* Hashtable should no longer be empty. */ > > + KUNIT_EXPECT_FALSE(test, hash_empty(hash)); > > +} > > + > > +static void hashtable_test_hash_hashed(struct kunit *test) > > +{ > > + struct hashtable_test_entry a, b; > > + DEFINE_HASHTABLE(hash, 3); > > + > > + hash_init(hash); > > + a.key = 1; > > + a.data = 13; > > + b.key = 1; > > + b.data = 2; > > + > > + hash_add(hash, &a.node, a.key); > > + hash_add(hash, &b.node, b.key); > > + > > + KUNIT_EXPECT_TRUE(test, hash_hashed(&a.node)); > > + KUNIT_EXPECT_TRUE(test, hash_hashed(&b.node)); > > +} > > + > > +static void hashtable_test_hash_add(struct kunit *test) > > +{ > > + struct hashtable_test_entry a, b, *x; > > + int bkt; > > + DEFINE_HASHTABLE(hash, 3); > > + > > + hash_init(hash); > > + a.key = 1; > > + a.data = 13; > > + a.visited = 0; > > + b.key = 2; > > + b.data = 10; > > + b.visited = 0; > > + > > + hash_add(hash, &a.node, a.key); > > + hash_add(hash, &b.node, b.key); > > + > > + hash_for_each(hash, bkt, x, node) { > > + if (x->key == a.key && x->data == a.data) > > + a.visited += 1; > > + if (x->key == b.key && x->data == b.data) > > + b.visited += 1; > > + } > > x->visited += 1; > or > x->visited++; > also do the same thing. Oh right. That makes a lot of sense. > > Note: given x is supposed to point to a or b, I don't know if checking > against a.data does us much good. > If we're trying to check that hash_add() doesn't mutate the keys and > data, this code won't catch it. > We'd have to instead do something like > if(x->key != 1 && x->key != 2) KUNIT_FAIL(test, ...); > This seems like a good change to me in combination with changing it to x->visited++;. Although David's suggestion might be slightly more exhaustive. Why wouldn't it be important to check that the key matches the data? > > + > > + /* Both entries should have been visited exactly once. */ > > + KUNIT_EXPECT_EQ(test, a.visited, 1); > > + KUNIT_EXPECT_EQ(test, b.visited, 1); > > +} > > + > > +static void hashtable_test_hash_del(struct kunit *test) > > +{ > > + struct hashtable_test_entry a, b, *x; > > + DEFINE_HASHTABLE(hash, 3); > > + > > + hash_init(hash); > > + a.key = 1; > > + a.data = 13; > > + b.key = 2; > > + b.data = 10; > > + b.visited = 0; > > + > > + hash_add(hash, &a.node, a.key); > > + hash_add(hash, &b.node, b.key); > > + > > + hash_del(&b.node); > > + hash_for_each_possible(hash, x, node, b.key) { > > + if (x->key == b.key && x->data == b.data) > > + b.visited += 1; > > Similarly to above, x->visited += 1 (or ++) is probably better. Right. Will switch this out here. > > > + } > > + > > + /* The deleted entry should not have been visited. */ > > + KUNIT_EXPECT_EQ(test, b.visited, 0); > > + > > + hash_del(&a.node); > > + > > + /* The hashtable should be empty. */ > > + KUNIT_EXPECT_TRUE(test, hash_empty(hash)); > > +} > > + > > +static void hashtable_test_hash_for_each(struct kunit *test) > > +{ > > + struct hashtable_test_entry entries[3]; > > + struct hashtable_test_entry *x; > > + int bkt, i, j, count; > > + DEFINE_HASHTABLE(hash, 3); > > + > > + /* Initialize a hashtable with three entries. */ > > + hash_init(hash); > > + for (i = 0; i < 3; i++) { > > + entries[i].key = i; > > + entries[i].data = i + 10; > > + entries[i].visited = 0; > > + hash_add(hash, &entries[i].node, entries[i].key); > > + } > > + > > + count = 0; > > + hash_for_each(hash, bkt, x, node) { > > + if (x->key >= 0 && x->key < 3) > > + entries[x->key].visited += 1; > > Would this be better using an assert to fail the test if we see unexpected keys? > E.g. like > if (x->key < 0 || x->key > 3) KUNIT_ASSERT_FAILURE(test, ...); > x->visited++; > count++; > or > KUNIT_ASSERT_GE(test, x->key, 0); > KUNIT_ASSERT_LT(test, x->key, 3); Yes, this makes a lot of sense. I will switch out just the if statements for using assert statements. > > > + count++; > > + } > > + > > + /* Should have visited each entry exactly once. */ > > + KUNIT_EXPECT_EQ(test, count, 3); > > + for (j = 0; j < 3; j++) > > + KUNIT_EXPECT_EQ(test, entries[j].visited, 1); > > +} > > + > > +static void hashtable_test_hash_for_each_safe(struct kunit *test) > > +{ > > + struct hashtable_test_entry entries[3]; > > + struct hashtable_test_entry *x; > > + struct hlist_node *tmp; > > + int bkt, i, j, count; > > + DEFINE_HASHTABLE(hash, 3); > > + > > + /* Initialize a hashtable with three entries. */ > > + hash_init(hash); > > + for (i = 0; i < 3; i++) { > > + entries[i].key = i; > > + entries[i].data = i + 10; > > + entries[i].visited = 0; > > + hash_add(hash, &entries[i].node, entries[i].key); > > + } > > + > > + count = 0; > > + hash_for_each_safe(hash, bkt, tmp, x, node) { > > + if (x->key >= 0 && x->key < 3) { > > + entries[x->key].visited += 1; > > + hash_del(&entries[x->key].node); > > + } > > + count++; > > + } > > + > > + /* Should have visited each entry exactly once. */ > > + KUNIT_EXPECT_EQ(test, count, 3); > > + for (j = 0; j < 3; j++) > > + KUNIT_EXPECT_EQ(test, entries[j].visited, 1); > > +} > > + > > +static void hashtable_test_hash_for_each_possible(struct kunit *test) > > +{ > > + struct hashtable_test_entry entries[4]; > > + struct hashtable_test_entry *x; > > + int i, j, count; > > + DEFINE_HASHTABLE(hash, 3); > > + > > + /* Initialize a hashtable with three entries with key = 1. */ > > + hash_init(hash); > > + for (i = 0; i < 3; i++) { > > + entries[i].key = 1; > > + entries[i].data = i; > > + entries[i].visited = 0; > > + hash_add(hash, &entries[i].node, entries[i].key); > > + } > > + > > + /* Add an entry with key = 2. */ > > + entries[3].key = 2; > > + entries[3].data = 3; > > + entries[3].visited = 0; > > + hash_add(hash, &entries[3].node, entries[3].key); > > + > > + count = 0; > > + hash_for_each_possible(hash, x, node, 1) { > > + if (x->data >= 0 && x->data < 4) > > + entries[x->data].visited += 1; > > + count++; > > + } > > + > > + /* Should have visited each entry with key = 1 exactly once. */ > > + for (j = 0; j < 3; j++) > > + KUNIT_EXPECT_EQ(test, entries[j].visited, 1); > > + > > + /* If entry with key = 2 is in the same bucket as the entries with > > + * key = 1, check it was visited. Otherwise ensure that only three > > + * entries were visited. > > + */ > > + if (hash_min(1, HASH_BITS(hash)) == hash_min(2, HASH_BITS(hash))) { > > nit: this feels like we might be a bit too tied to the impl (not sure > if it'll change anytime soon, but still). > > Could we check the bucket using hash_for_each? > E.g. > > // assume we change the keys from {1,2} to {0,1} > int buckets[2]; > hash_for_each(hash, bkt, x, node) { > buckets[x->key] = bkt; > } > > if (buckets[0] == buckets[1]) { // all in the same bucket > ... > } else { ... } I really like the idea of using hash_for_each to determine the bucket. I will add this to the test. > > > + KUNIT_EXPECT_EQ(test, count, 4); > > + KUNIT_EXPECT_EQ(test, entries[3].visited, 1); > > + } else { > > + KUNIT_EXPECT_EQ(test, count, 3); > > should we also check that entries[3].visited == 0? Right. Must have been a mistake on my end. Oops. > > Daniel Thanks Daniel! -Rae