Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1114579iob; Thu, 12 May 2022 11:24:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxDgslSdSp8c39sh/WgMq+EXGnERHnEbiU1VL30U8/oLx3NvGnLVpVGSWVbzsSDs8Ce49v7 X-Received: by 2002:a17:907:6d17:b0:6f4:6b6e:32da with SMTP id sa23-20020a1709076d1700b006f46b6e32damr1088318ejc.301.1652379872376; Thu, 12 May 2022 11:24:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652379872; cv=none; d=google.com; s=arc-20160816; b=VCvvAEVAu2Z6fpsCSX1K5VTjrBk4zSmLougbBdkImAYXiCWeyTy6kp2oKLxX0vtL8J YnqsQSiQ2cdkNMQjA2mDuWuRKbP2iIPn4t95JgKYpFyxwL/DUqDh7fIxjknvXj8SjiYq Ef9mOjkXHu1jHm4ALRXxtMWfhWG83R72TgKtQiptFBlb74CqbH2BCz4dutN5yuuU4fVL Hv9hRvhHAwzvKdis53ZgXVna8X+Ypr2g/MVzi+k3IXPGnWPauMCIvRx3AiJPJrVBh5fB mUkM6/8zhDpP5T2fMKTTmw8G1Ym31v2t+3V/ZZpe5HE91wcXjlXr3R7NUTp3jX2K4J9L UlHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id :dkim-signature; bh=9YHAxVCwMQX+pkLG4apffaFkY79VVK11xX1H1uNWoZU=; b=TanpCn7sSO0ZBUwiTt5Pjaiyp/ocEOmi87glpVgov05cU/vWJF6N6ENja4sfdvARlo wgaB15DMFvf1ZRtUOJN9UAOBO4sOhreDIDD81RUBPWMJ+o2sHlUpFPA//s/ngfIRxRog Y3JknCwNQNIT87wwcvQIIok7AhkUASYT30l2eU2QQfRXImP/3STAb6HPa3Kwgjc11Eyn qZ41LOjRR0mOFmclqsEamV7fUg4IrlqTl1Ke+pX173E9pkgGUNWni3zZMJnzzxi4ykpZ zlJL0Y1kxfOSSvsg07LjSZBqBI3k7H7RinrFuXxIBuBFBWi7L4LdTZAskuB2B+CVMFb/ 2ZnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=ScQXX34k; 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=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ds11-20020a170907724b00b006e8c12d426csi7404117ejc.1002.2022.05.12.11.24.06; Thu, 12 May 2022 11:24:32 -0700 (PDT) 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=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=ScQXX34k; 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=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345368AbiELD67 (ORCPT + 99 others); Wed, 11 May 2022 23:58:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344861AbiELD6z (ORCPT ); Wed, 11 May 2022 23:58:55 -0400 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C2E32717E for ; Wed, 11 May 2022 20:58:53 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id l11-20020a17090a49cb00b001d923a9ca99so3781873pjm.1 for ; Wed, 11 May 2022 20:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:to:cc:references :from:in-reply-to:content-transfer-encoding; bh=9YHAxVCwMQX+pkLG4apffaFkY79VVK11xX1H1uNWoZU=; b=ScQXX34kCFkg6LTVK5Bzh9wpxADbH4wZ2ElWqdVAhelSVmQCmHBJ5xv35LfYe4zUNt P3tVg3LOYPpBbRkXg0TyHtFhp4yRfd/6UOxaOA2A3x8Ltw3+t/MAdOxWTFHo2hN3dwYZ bvh4QfM3chkDhBDZFHZ1BDO9OOFLr89R+WaAhwmo7uidQMACOoqXWPBui/uJXHo/ZZXu jJY6C3R5s3F/1AV7o0m2OKZmp80ce0TqdBlk63hV+XT3iKEaNiDKbOI/aEYoqZFDcGyk Q71v8VRIrocJmsSEGBxWbOWgfxSvQga7LpGOCENbmx7+y67sc78rTONkFyaX4Z2D71yI vKtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :to:cc:references:from:in-reply-to:content-transfer-encoding; bh=9YHAxVCwMQX+pkLG4apffaFkY79VVK11xX1H1uNWoZU=; b=0N/5iU2Iw3XO+NR2cib/MlrSLD2Wdi6VA1fTqyL0xjy+b71s5TwgT9yxaA5rewjcHv K75IWsClvwIbI3t2OyPlqUs5bFSbXsFK+MY3kQhCGRI5LAiEfWO7oufCZrzYxxe0mZhQ zcSW0l/L49D61DCMTqSLrsfUryxyUIVvEOpTfThyLgh8tVqEbLf+9LAYumG2nsLReJla ltksjZCxP4L+caHaP+l6I5oWAqSLrvwJNMwpVTKmRtSb+SmtDbYL0cNqSMHRQiDOhyrn VKfmguqZFUoJrkoo81pLSMuA3CrtOctfV9v91UUqvcFWOMEi1l9AWmNegg6UsBLPrI/4 m6ew== X-Gm-Message-State: AOAM531NK32CGtJsJuwJcDWG/A1wioB3T5858AcdjDZXa0CfSUgVgTgQ vLMHxkfENB8uC6M6xG8wdPyjeQ== X-Received: by 2002:a17:90b:4f87:b0:1dd:100b:7342 with SMTP id qe7-20020a17090b4f8700b001dd100b7342mr8703718pjb.64.1652327932987; Wed, 11 May 2022 20:58:52 -0700 (PDT) Received: from [10.71.57.194] ([139.177.225.225]) by smtp.gmail.com with ESMTPSA id y10-20020a1709027c8a00b0015e8d4eb234sm2654861pll.126.2022.05.11.20.58.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 May 2022 20:58:52 -0700 (PDT) Message-ID: <731c281a-9911-fa86-fec2-a3c1a3954461@bytedance.com> Date: Thu, 12 May 2022 11:58:38 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: [External] Re: [PATCH bpf-next v2 2/2] selftests/bpf: add test case for bpf_map_lookup_percpu_elem To: Andrii Nakryiko Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin Lau , Song Liu , Yonghong Song , john fastabend , KP Singh , Steven Rostedt , Ingo Molnar , Jiri Olsa , Dave Marchevsky , Joanne Koong , Geliang Tang , Networking , bpf , open list , duanxiongchun@bytedance.com, Muchun Song , Dongdong Wang , Cong Wang , zhouchengming@bytedance.com, yosryahmed@google.com References: <20220511093854.411-1-zhoufeng.zf@bytedance.com> <20220511093854.411-3-zhoufeng.zf@bytedance.com> From: Feng Zhou In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham 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 在 2022/5/12 上午11:34, Andrii Nakryiko 写道: > On Wed, May 11, 2022 at 2:39 AM Feng zhou wrote: >> From: Feng Zhou >> >> test_progs: >> Tests new ebpf helpers bpf_map_lookup_percpu_elem. >> >> Signed-off-by: Feng Zhou >> --- >> .../bpf/prog_tests/map_lookup_percpu_elem.c | 46 ++++++++++++++++ >> .../bpf/progs/test_map_lookup_percpu_elem.c | 54 +++++++++++++++++++ >> 2 files changed, 100 insertions(+) >> create mode 100644 tools/testing/selftests/bpf/prog_tests/map_lookup_percpu_elem.c >> create mode 100644 tools/testing/selftests/bpf/progs/test_map_lookup_percpu_elem.c >> >> diff --git a/tools/testing/selftests/bpf/prog_tests/map_lookup_percpu_elem.c b/tools/testing/selftests/bpf/prog_tests/map_lookup_percpu_elem.c >> new file mode 100644 >> index 000000000000..58b24c2112b0 >> --- /dev/null >> +++ b/tools/testing/selftests/bpf/prog_tests/map_lookup_percpu_elem.c >> @@ -0,0 +1,46 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +// Copyright (c) 2022 Bytedance > /* */ instead of // Ok, I will do. Thanks. > >> + >> +#include >> + >> +#include "test_map_lookup_percpu_elem.skel.h" >> + >> +#define TEST_VALUE 1 >> + >> +void test_map_lookup_percpu_elem(void) >> +{ >> + struct test_map_lookup_percpu_elem *skel; >> + int key = 0, ret; >> + int nr_cpus = sysconf(_SC_NPROCESSORS_ONLN); > I think this is actually wrong and will break selftests on systems > with offline CPUs. Please use libbpf_num_possible_cpus() instead. Ok, I will do. Thanks. > >> + int *buf; >> + >> + buf = (int *)malloc(nr_cpus*sizeof(int)); >> + if (!ASSERT_OK_PTR(buf, "malloc")) >> + return; >> + memset(buf, 0, nr_cpus*sizeof(int)); > this is wrong, kernel expects to have roundup(sz, 8) per each CPU, > while you have just 4 bytes per each element > > please also have spaces around multiplication operator here and above Ok, I will use 8 bytes for key and val. Thanks. >> + buf[0] = TEST_VALUE; >> + >> + skel = test_map_lookup_percpu_elem__open_and_load(); >> + if (!ASSERT_OK_PTR(skel, "test_map_lookup_percpu_elem__open_and_load")) >> + return; > buf leaking here Yes, sorry for my negligence. > >> + ret = test_map_lookup_percpu_elem__attach(skel); >> + ASSERT_OK(ret, "test_map_lookup_percpu_elem__attach"); >> + >> + ret = bpf_map_update_elem(bpf_map__fd(skel->maps.percpu_array_map), &key, buf, 0); >> + ASSERT_OK(ret, "percpu_array_map update"); >> + >> + ret = bpf_map_update_elem(bpf_map__fd(skel->maps.percpu_hash_map), &key, buf, 0); >> + ASSERT_OK(ret, "percpu_hash_map update"); >> + >> + ret = bpf_map_update_elem(bpf_map__fd(skel->maps.percpu_lru_hash_map), &key, buf, 0); >> + ASSERT_OK(ret, "percpu_lru_hash_map update"); >> + >> + syscall(__NR_getuid); >> + >> + ret = skel->bss->percpu_array_elem_val == TEST_VALUE && >> + skel->bss->percpu_hash_elem_val == TEST_VALUE && >> + skel->bss->percpu_lru_hash_elem_val == TEST_VALUE; >> + ASSERT_OK(!ret, "bpf_map_lookup_percpu_elem success"); > this would be better done as three separate ASSERT_EQ(), combining > into opaque true/false isn't helpful if something breaks Good suggestion. > >> + >> + test_map_lookup_percpu_elem__destroy(skel); >> +} >> diff --git a/tools/testing/selftests/bpf/progs/test_map_lookup_percpu_elem.c b/tools/testing/selftests/bpf/progs/test_map_lookup_percpu_elem.c >> new file mode 100644 >> index 000000000000..5d4ef86cbf48 >> --- /dev/null >> +++ b/tools/testing/selftests/bpf/progs/test_map_lookup_percpu_elem.c >> @@ -0,0 +1,54 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +// Copyright (c) 2022 Bytedance > /* */ instead of // Ok, I will do. Thanks. > >> + >> +#include "vmlinux.h" >> +#include >> + >> +int percpu_array_elem_val = 0; >> +int percpu_hash_elem_val = 0; >> +int percpu_lru_hash_elem_val = 0; >> + >> +struct { >> + __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY); >> + __uint(max_entries, 1); >> + __type(key, __u32); >> + __type(value, __u32); >> +} percpu_array_map SEC(".maps"); >> + >> +struct { >> + __uint(type, BPF_MAP_TYPE_PERCPU_HASH); >> + __uint(max_entries, 1); >> + __type(key, __u32); >> + __type(value, __u32); >> +} percpu_hash_map SEC(".maps"); >> + >> +struct { >> + __uint(type, BPF_MAP_TYPE_LRU_PERCPU_HASH); >> + __uint(max_entries, 1); >> + __type(key, __u32); >> + __type(value, __u32); >> +} percpu_lru_hash_map SEC(".maps"); >> + >> +SEC("tp/syscalls/sys_enter_getuid") >> +int sysenter_getuid(const void *ctx) >> +{ >> + __u32 key = 0; >> + __u32 cpu = 0; >> + __u32 *value; >> + >> + value = bpf_map_lookup_percpu_elem(&percpu_array_map, &key, cpu); >> + if (value) >> + percpu_array_elem_val = *value; >> + >> + value = bpf_map_lookup_percpu_elem(&percpu_hash_map, &key, cpu); >> + if (value) >> + percpu_hash_elem_val = *value; >> + >> + value = bpf_map_lookup_percpu_elem(&percpu_lru_hash_map, &key, cpu); >> + if (value) >> + percpu_lru_hash_elem_val = *value; >> + > if the test happens to run on CPU 0 then the test doesn't really test > much. It would be more interesting to have a bpf_loop() iteration that > would fetch values on each possible CPU instead and do something with > it. Good suggestion. I check the code and find no bpf helper function to get possible CPU nums. I think for the test function, read cpu0 elem value correctly should be considered to be no problem. Or is it necessary to add a new helper function to get num_possible_cpus ? > >> + return 0; >> +} >> + >> +char _license[] SEC("license") = "GPL"; >> -- >> 2.20.1 >>