Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2490296pxk; Mon, 14 Sep 2020 15:07:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwDnn+SbR3DNw4Tf+G9iK95ZV18nlL3pxEPcj4k9w4pgt7pa0kHtpWd8EOvsFRFBcg9l5bw X-Received: by 2002:a17:906:934e:: with SMTP id p14mr16565612ejw.348.1600121273531; Mon, 14 Sep 2020 15:07:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600121273; cv=none; d=google.com; s=arc-20160816; b=DGyJmd9uikntQFEigwK+VN3p5ddlw8/fG/QoXGRLok6mF051HlNf+QjQCgGuzp0i3A rL4Rljh+3jg6WNxv5CTQjNMOAz37AK5Usranv7XSJhRh43hw478AMf+pMvdogVm5SCjP nw0Irq9nNJEt3aPGfZUNyp/MYB9LrKdPAUTIvLLTuAHrVtdT2lNGYpLtCd75Tpr49TQJ Pdrbhd/5RhgJ1mrCe2EKjAVRKP7IxwbaHIO8ZhInVDZNXsdJkoAzzfmrDuXaV6STCncq in2XHTNDjIzOAJ93OBXakaPY2FIg4SdMffI/dm80wiBWAJzjQCHFCltEd08pq37FSrBn DuUw== 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=qjXTDrZsJtVC0UTN/zfoow5ilYHg2sYH2n/teLc5H/4=; b=d8nJeiNKUFwEKJMMpm0JWcFnwy85hMiEAj//idina7J9cC1SMPvooUM5gzC4v6CBgI Y6gNtMCbdBAwnNmpZBzSu35NT9GU12WP+LTkrSpZwoM5SxyDaXceGGrxmfXMGgDgCF4e egw5ROf/7Q/NucC6VaZmMXwxUO8qcTHC2jlxv38Efg3zGlCajhI2k5Q9L/RIhiNrP+1c MugwrBwDxWsh+jNNFM2l88rF6QiMQzpaqruJfUqypwdN+QNzk86uLBFmzonosvpwzSSZ P2hNm+V9x3G9x0qJuKNkW/HdVgeK0ESe0zJvEX0deMiDTe30Go6YjrYXa2h/CsIYshez k/hQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Qw6cBHvS; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l14si7631889eje.378.2020.09.14.15.07.31; Mon, 14 Sep 2020 15:07:53 -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=@gmail.com header.s=20161025 header.b=Qw6cBHvS; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726064AbgINWGg (ORCPT + 99 others); Mon, 14 Sep 2020 18:06:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52394 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725926AbgINWGc (ORCPT ); Mon, 14 Sep 2020 18:06:32 -0400 Received: from mail-yb1-xb43.google.com (mail-yb1-xb43.google.com [IPv6:2607:f8b0:4864:20::b43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6935DC06174A; Mon, 14 Sep 2020 15:06:31 -0700 (PDT) Received: by mail-yb1-xb43.google.com with SMTP id h126so995411ybg.4; Mon, 14 Sep 2020 15:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qjXTDrZsJtVC0UTN/zfoow5ilYHg2sYH2n/teLc5H/4=; b=Qw6cBHvSogrZmbGiHDwR7HFjNftujO7Sd6TjpwZvPkcwwL6NUS7qjbunscoh9ES0lR xFVtL6bkHXKZ3i5EW0egCPiVlm74VnAUVTSZRJvNCm6j+nXJr14xH4JViYXRA3BkBtbd ip4fS5NwcORHLqI7pdnPcA6Ji8czYXjdAOLu1JP55sZQoKATNjDbqoZNPx5IkATUvtIL pHtV4uKmhr8Qx3g4bhmAzcyNLm0LEErHfqRuTuvk/eFWCa2bemYuBIO2xXD1BKitnSUd wtzslH7FXex4cGT/G00Fmpwg5tk4DO7tsF/FXhZXIc9+7a1z5knakeqRsPmZEqcd+uD+ Gzwg== 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=qjXTDrZsJtVC0UTN/zfoow5ilYHg2sYH2n/teLc5H/4=; b=bjlo4x7d/e32GQjuD2rEsCrAsuyvSVL7ezr2jM5zUoZqT7dsg414SNx7vIdjzGJtm0 gDFQPZ141oBF4QiHEVC/7YgLT6i0hUhmqrkccPvykcHpz7nUSNLwNtDnFOXE0wMB50E3 uck+eCH4z5dLIGhWBxu46uZ5bkD1gNKbfyTA+xr/AhpSbS/qgfW7pta9HLqXZHRb53fB cHRwvNaUgRZljP/nyxOayhgcehgkptHYYEvaAk5fFKY76tc01YtI7aXT0VQTqGNUAEFC s18p3MjGwgVYeZRQ8zfdezs339TVEywFnTIP9y/iiHTNnUEu3VtLwUkVPgeGp+2F28yV TrTQ== X-Gm-Message-State: AOAM530H7cizaqfBsGaZ7aZO6sxPNsUI4I2drnl2XTlbsMA4RFsGgZd+ 34KitNCNF+/xuXJqHgr5bjmyA+gltL1lG/CMk6g= X-Received: by 2002:a25:33c4:: with SMTP id z187mr10197978ybz.27.1600121190211; Mon, 14 Sep 2020 15:06:30 -0700 (PDT) MIME-Version: 1.0 References: <20200903223332.881541-1-haoluo@google.com> <20200903223332.881541-4-haoluo@google.com> In-Reply-To: From: Andrii Nakryiko Date: Mon, 14 Sep 2020 15:06:18 -0700 Message-ID: Subject: Re: [PATCH bpf-next v2 3/6] bpf/selftests: ksyms_btf to test typed ksyms To: Hao Luo Cc: Networking , bpf , open list , "open list:KERNEL SELFTEST FRAMEWORK" , Shuah Khan , Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , 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 Sun, Sep 13, 2020 at 9:58 PM Hao Luo wrote: > > Thanks for taking a look, Andrii. > > On Fri, Sep 4, 2020 at 12:49 PM Andrii Nakryiko > wrote: > > > > On Thu, Sep 3, 2020 at 3:35 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 > > > --- > > > .../testing/selftests/bpf/prog_tests/ksyms.c | 31 +++------ > > > .../selftests/bpf/prog_tests/ksyms_btf.c | 63 +++++++++++++++++++ > > > .../selftests/bpf/progs/test_ksyms_btf.c | 23 +++++++ > > > tools/testing/selftests/bpf/trace_helpers.c | 26 ++++++++ > > > tools/testing/selftests/bpf/trace_helpers.h | 4 ++ > > > 5 files changed, 123 insertions(+), 24 deletions(-) > > > create mode 100644 tools/testing/selftests/bpf/prog_tests/ksyms_btf.c > > > create mode 100644 tools/testing/selftests/bpf/progs/test_ksyms_btf.c > > > > [...] > > > + > > > +extern const struct rq runqueues __ksym; /* struct type global var. */ > > > +extern const int bpf_prog_active __ksym; /* int type global var. */ > > > > When we add non-per-CPU kernel variables, I wonder if the fact that we > > have both per-CPU and global kernel variables under the same __ksym > > section would cause any problems and confusion? It's not clear to me > > if we need to have a special __percpu_ksym section or not?.. > > > > Yeah. Totally agree. I thought about this. I think a separate > __percpu_ksym attribute is *probably* more clear. Not sure though. How > about we introduce a "__percpu_ksym" and make it an alias to "__ksym" > for now? If needed, we make an actual section for it in future. Let's keep it in __ksym as is. Verifier will have enough insight to produce a meaningful error message, it won't be easy to misuse this feature. > > > > + > > > +SEC("raw_tp/sys_enter") > > > +int handler(const void *ctx) > > > +{ > > > + out__runqueues = (__u64)&runqueues; > > > + out__bpf_prog_active = (__u64)&bpf_prog_active; > > > + > > > + return 0; > > > +} > > > + > > > +char _license[] SEC("license") = "GPL"; > > > diff --git a/tools/testing/selftests/bpf/trace_helpers.c b/tools/testing/selftests/bpf/trace_helpers.c > > > index 4d0e913bbb22..ade555fe8294 100644 > > > --- a/tools/testing/selftests/bpf/trace_helpers.c > > > +++ b/tools/testing/selftests/bpf/trace_helpers.c > > > @@ -90,6 +90,32 @@ long ksym_get_addr(const char *name) > > > return 0; > > > } > > > > > > +/* open kallsyms and read symbol addresses on the fly. Without caching all symbols, > > > + * this is faster than load + find. */ > > > +int kallsyms_find(const char *sym, unsigned long long *addr) > > > +{ > > > + char type, name[500]; > > > + unsigned long long value; > > > + int err = 0; > > > + FILE *f; > > > + > > > + f = fopen("/proc/kallsyms", "r"); > > > + if (!f) > > > + return -ENOENT; > > > + > > > + while (fscanf(f, "%llx %c %499s%*[^\n]\n", &value, &type, name) > 0) { > > > + if (strcmp(name, sym) == 0) { > > > + *addr = value; > > > + goto out; > > > + } > > > + } > > > + err = -EINVAL; > > > > These error codes seem backward to me. If you fail to open > > /proc/kallsyms, that's an unexpected and invalid situation, so EINVAL > > makes a bit more sense there. But -ENOENT is clearly for cases where > > you didn't find what you were looking for, which is exactly this case. > > > > > > I thought about it. I used -ENOENT for fopen failure because I found > -ENOENT is for the case when a file/directory is not found, which is > more reasonable in describing fopen error. But your proposal also > makes sense and that is what I originally had. It doesn't sound like > a big deal, I can switch the order them in v3. For me, ENOENT is about the logical entity the function is working with. For fopen() that would be file, so if it's not found -- ENOENT. But here, for kallsyms_find it's a ksym. If /proc/kallsyms isn't there or can't be open -- that's unexpected (EINVAL). But if /proc/kallsyms was open but didn't contain the entity we are looking for (requested ksym) -- that's ENOENT. > > > > + > > > +out: > > > + fclose(f); > > > + return err; > > > +} > > > + > > > void read_trace_pipe(void) > > > { > > > int trace_fd; > > > diff --git a/tools/testing/selftests/bpf/trace_helpers.h b/tools/testing/selftests/bpf/trace_helpers.h > > > index 25ef597dd03f..f62fdef9e589 100644 > > > --- a/tools/testing/selftests/bpf/trace_helpers.h > > > +++ b/tools/testing/selftests/bpf/trace_helpers.h > > > @@ -12,6 +12,10 @@ struct ksym { > > > int load_kallsyms(void); > > > struct ksym *ksym_search(long key); > > > long ksym_get_addr(const char *name); > > > + > > > +/* open kallsyms and find addresses on the fly, faster than load + search. */ > > > +int kallsyms_find(const char *sym, unsigned long long *addr); > > > + > > > void read_trace_pipe(void); > > > > > > #endif > > > -- > > > 2.28.0.526.ge36021eeef-goog > > >