Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp809256pxa; Sat, 22 Aug 2020 00:28:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwUGH0lDvG2kjDNGrGpuX4YosmfpiUm7a/0w278jDkgWqUgAkY88B0dZo6wF3EJAJo2fQOR X-Received: by 2002:a17:906:fcdb:: with SMTP id qx27mr6151734ejb.421.1598081289103; Sat, 22 Aug 2020 00:28:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598081289; cv=none; d=google.com; s=arc-20160816; b=QGy9PW8gv6qTJVASFCRe8JbsBBV3hqqCSH5sGQGDJe1M2Vl2KnTaHVCF0LGAVXMaJp 8nznMxdfz3t7KfNax2FVLTy4XDj0Am/UD9Lo6I3NoGPp0C8iutI8NTVEABOo63jYWmaZ 69sjfvzKLeASz+jy3xzbFUFJvFnYqHir2t0dcFr6p3+bOfNQTqvbWGnLGcXah3IWUeNN 45rzS0xm+MZkUfvlLeG7BkvOQkiwmSTKQYrniaVd+T8vj3IkZnIN9Q/B1YJ2UUMn+yUE Ib5oKdLlFrm2uCZtvw2TrSD6ol2SEMTCdhNf5RxjxFQ4UXhFk6tbn2eAZGHekaWFi32e KHbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=mDR0zrvaETchAvJrcviqkk7cP258seKos1RRZO2tCNY=; b=JZNE2ABZNTLYraRVQYVMIECZej7d+y5OJu5or3bwf4rs8TKScOZIqDmgbPipWOhsyS 4Dt4OAhMKwVZ5rMNTyqX/SzXcv/aQGFhjtSWl8x3CKFNxuenWZFbaxebPMTKyaduyn9G 2zKevOzV7IIFNduby8S/hKG/iq5/5nr2HFmLnBeAJXXfCIhVwE1euLAJafhWgMeWN4yE OAKqXMYGFmUz/lUajtOz+WQ+DjTQ3x7Esi/2cPRxz9ZaXfUSsSQE1UWki8/FTSmsTsqj ZoUMh/tEhUFXRMBB8fuEjKMgEqMC7HAwD0Uy4w9Nj4BZ+noMree/hSWuZol/cgJEzTvQ /J7w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=WD1y4zXx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id zg2si2958689ejb.183.2020.08.22.00.27.45; Sat, 22 Aug 2020 00:28:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=WD1y4zXx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1727017AbgHVH1O (ORCPT + 99 others); Sat, 22 Aug 2020 03:27:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59992 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725975AbgHVH1K (ORCPT ); Sat, 22 Aug 2020 03:27:10 -0400 Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 71569C061573 for ; Sat, 22 Aug 2020 00:27:10 -0700 (PDT) Received: by mail-ej1-x642.google.com with SMTP id oz20so216617ejb.5 for ; Sat, 22 Aug 2020 00:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mDR0zrvaETchAvJrcviqkk7cP258seKos1RRZO2tCNY=; b=WD1y4zXxFKdPhrJDo7FZF18V8FXHdZAuQzKOqvwg5t4cC+zK1OJ0lfC/t6NmK+O6GG NWICiBh3SfaXsrWidpT/L8d81C880rZzPxlK3xjlS6gvz8POZsgYaj1nm5h7681zVqSV SaLXPjSsR0MQQbKtVGF/UuK00EXO3tq9Z/BrHW4scNC3phcxBiqQTa+lRN2e+V9gs4H1 Yh0+8sRw+4LfFgKuIyivx/UOICrzE7utfUuUFiRTd9EMaBWno18Zrmjq/MLKR0zOFkuv /2SWots2svp9DZ+wH63o3IPnu84631NxD5XC0nxh1ZI8AtBGWMS0XSZwKSEVmSpYiYil LnnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mDR0zrvaETchAvJrcviqkk7cP258seKos1RRZO2tCNY=; b=Mo3qZ6IWZ0GmQaxmHUNe9BjHlM+EjfRmAQJXmimZaIu/uWJ7Fe0dDP3czfnFNiLQdP I4tbYfSXgL7Euhp6cmwMWFcSSkq9JRlVuWDwXHEjjA2c1fa1wB18SFxSCcuIeYy6slPo oToGDI/GYDQWtlAOra3zDdgGu9ADlG1Zb1KIsNH+Xqc2VF69GtGE+Lf7jMXcsut0FetM g3Etxry6BKT4Fh+7HmoXgjctGpcey76t8rwssMsWXaMrBKCslDDZZdPosvM3tGGagM/N ogjZxtwpG7gjbVBulZrMN98tWGHxaSzLJmhwVNtZ2ou6AJLPKXr7W2BpAEO+li0XWd5r Uh6Q== X-Gm-Message-State: AOAM533IXjH+KpPLCfrjC5kxzyPXGuHV4BzIZf/QSEyv4C/N5bziw+0b ekB+OrEm2+PgtmeOVdM5ebP7hLtO5tEjbAPlOyJb8g== X-Received: by 2002:a17:906:5902:: with SMTP id h2mr6586238ejq.423.1598081228742; Sat, 22 Aug 2020 00:27:08 -0700 (PDT) MIME-Version: 1.0 References: <20200819224030.1615203-1-haoluo@google.com> <20200819224030.1615203-6-haoluo@google.com> <29b8358f-64fb-9e82-acb0-20b5922afc81@fb.com> In-Reply-To: From: Hao Luo Date: Sat, 22 Aug 2020 00:26:57 -0700 Message-ID: Subject: Re: [PATCH bpf-next v1 5/8] bpf/selftests: ksyms_btf to test typed ksyms To: Andrii Nakryiko Cc: Yonghong Song , Networking , bpf , open list , "open list:KERNEL SELFTEST FRAMEWORK" , Shuah Khan , Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Martin KaFai Lau , Song Liu , John Fastabend , KP Singh , Quentin Monnet , Steven Rostedt , Ingo Molnar , Andrey Ignatov , Jakub Sitnicki Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 21, 2020 at 4:03 PM Andrii Nakryiko wrote: > > On Thu, Aug 20, 2020 at 10:32 AM Yonghong Song wrote: > > > > > > > > On 8/19/20 3:40 PM, Hao Luo wrote: > > > Selftests for typed ksyms. Tests two types of ksyms: one is a struct, > > > the other is a plain int. This tests two paths in the kernel. Struct > > > ksyms will be converted into PTR_TO_BTF_ID by the verifier while int > > > typed ksyms will be converted into PTR_TO_MEM. > > > > > > Signed-off-by: Hao Luo > > > --- > > > .../selftests/bpf/prog_tests/ksyms_btf.c | 77 +++++++++++++++++++ > > > .../selftests/bpf/progs/test_ksyms_btf.c | 23 ++++++ > > > 2 files changed, 100 insertions(+) > > > create mode 100644 tools/testing/selftests/bpf/prog_tests/ksyms_btf.c > > > create mode 100644 tools/testing/selftests/bpf/progs/test_ksyms_btf.c > > > > > > diff --git a/tools/testing/selftests/bpf/prog_tests/ksyms_btf.c b/tools/testing/selftests/bpf/prog_tests/ksyms_btf.c > > > new file mode 100644 > > > index 000000000000..1dad61ba7e99 > > > --- /dev/null > > > +++ b/tools/testing/selftests/bpf/prog_tests/ksyms_btf.c > > > @@ -0,0 +1,77 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* Copyright (c) 2020 Google */ > > > + > > > +#include > > > +#include > > > +#include > > > +#include "test_ksyms_btf.skel.h" > > > + > > > +static int duration; > > > + > > > +static __u64 kallsyms_find(const char *sym) > > > +{ > > > + char type, name[500]; > > > + __u64 addr, res = 0; > > > + FILE *f; > > > + > > > + f = fopen("/proc/kallsyms", "r"); > > > + if (CHECK(!f, "kallsyms_fopen", "failed to open: %d\n", errno)) > > > + return 0; > > > > could you check whether libbpf API can provide this functionality for > > you? As far as I know, libbpf does parse /proc/kallsyms. > > No need to use libbpf's implementation. We already have > kallsyms_find() in prog_tests/ksyms.c and a combination of > load_kallsyms() + ksym_get_addr() in trace_helpers.c. It would be good > to switch to one implementation for both prog_tests/ksyms.c and this > one. > Ack. I can do some refactoring. The least thing that I can do is moving kallsyms_find() to a header for both prog_tests/ksyms.c and this test to use. > > > > diff --git a/tools/testing/selftests/bpf/progs/test_ksyms_btf.c b/tools/testing/selftests/bpf/progs/test_ksyms_btf.c > > > new file mode 100644 > > > index 000000000000..e04e31117f84 > > > --- /dev/null > > > +++ b/tools/testing/selftests/bpf/progs/test_ksyms_btf.c > > > @@ -0,0 +1,23 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* Copyright (c) 2020 Google */ > > > + > > > +#include "vmlinux.h" > > > + > > > +#include > > > + > > > +__u64 out__runqueues = -1; > > > +__u64 out__bpf_prog_active = -1; > > > + > > > +extern const struct rq runqueues __ksym; /* struct type global var. */ > > > +extern const int bpf_prog_active __ksym; /* int type global var. */ > > > + > > > +SEC("raw_tp/sys_enter") > > > +int handler(const void *ctx) > > > +{ > > > + out__runqueues = (__u64)&runqueues; > > > + out__bpf_prog_active = (__u64)&bpf_prog_active; > > > + > > You didn't test accessing any of the members of runqueues, because BTF > only has per-CPU variables, right? Adding global/static variables was > adding too much data to BTF or something like that, is that right? > Right. With some experiments, I found the address of a percpu variable doesn't necessarily point to a valid structure. So it doesn't make sense to dereference runqueues and access its members. However, right now there are only percpu variables encoded in BTF, so I can't test accessing members of general global/static variables unfortunately. Hao