Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp186708rwr; Thu, 4 May 2023 17:10:43 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7yHRR6hBOnBjK03QHPl/B/t1nllRxKlNtKfmK9OHxqdGqQ7C3tzJxe1rWUWhG62zOmmHfj X-Received: by 2002:a17:90a:6481:b0:247:3895:e416 with SMTP id h1-20020a17090a648100b002473895e416mr3645463pjj.16.1683245442955; Thu, 04 May 2023 17:10:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683245442; cv=none; d=google.com; s=arc-20160816; b=h+mv8gGaBEYYsyYG+2TSDI98FaZ3eOIATLxqe186Mz+Aq9jqBqnk9TOii8d62DO3Cg iKO/N8JkWfEZXw5RdPW6ZUedFNHS3IK9VX/FdFk7kT4Xe7+4uzkvODdhCM9/iXtr/pRe c/VSvRHJE4c321fPk1paoU/SFtkRdSFEUAigSyTUyK5ZXQOO8jzncwDFFved79RD3cX3 YeVZxNzpCjTUGtA6BU5i0Dv6NUGwMUVabTUY63QrhJwsm0gkYet9rkbPfgHB9c2p9Dc6 OmPHyBSqkQgKPHJ62cpn4rMqykIte38HFjCGw4eZl65D3RoWbA1k0K7tuw9Yl/19v7I0 ufzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=jleM9mam0jC92K7s5TbbM7NijY+miJheeAbD3LOvDfA=; b=XZ5Bt/8+XvNEPq2JAdwFTIlFqk4E+uwcFYUP2jkefFFjh03SrumaOaxBisJiAWIBYl 3SNQETUdyAe4KIMSkXa/xQHC6ZyhqzqcNlXzfeys3Mam1TPtEUCe/jAt5mGylD+dlJD7 hsZewjw8MgDGxdtPODNUEIawO33tougKQI6KUscQMuGQB6WhtgfbPR+sbxoCgfkC8jiJ fQsItmImT3k0Jm0nl51gISnIaD2L47BFtQYAbKN3JU1pclpUqSgbdazs5bDkpnshIs5M Pg7G7RsvdMxoRZAxqSIdMV+E9c1LL1mZTJCfOb6qirxMwIIDuC6R70EKXAXZ+J8jA9a8 6gZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b="J90ITR/r"; 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 ot9-20020a17090b3b4900b00240c5503d04si53133pjb.152.2023.05.04.17.10.08; Thu, 04 May 2023 17:10:42 -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=@google.com header.s=20221208 header.b="J90ITR/r"; 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 S229816AbjEDXUC (ORCPT + 99 others); Thu, 4 May 2023 19:20:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229499AbjEDXUB (ORCPT ); Thu, 4 May 2023 19:20:01 -0400 Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CDEBA12E84 for ; Thu, 4 May 2023 16:19:59 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id e9e14a558f8ab-33124b0dd85so649435ab.1 for ; Thu, 04 May 2023 16:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683242399; x=1685834399; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jleM9mam0jC92K7s5TbbM7NijY+miJheeAbD3LOvDfA=; b=J90ITR/r2P88wH3CGkZ5u0W3j8eg6vs8I9cLw/l7YC559zhwlMFqmmhArwcq4/4USL s2DYaf7ejAnnO4A2Dmx814A2057D/RDduNBW3AlEsaSLsj8CkxuXzWjyZCiNsuuMxl3Z gLZp9aEm6VVRr5d9DFn0z8LiMMWLNftadj6TKQAI/VtsNGBxSqx15wpgOeaTs9XJNqgr 4iOChk7p9fPxJwE0UcItqEMpE+jqXpkEwgI3WJxsHCnlnzCw1EmyXJNplSisMytsK7iE UKkECc/oUuEb789YslJI/ZCtyFBQcymx7EQMM99KeHqNVweuv3K5CmXt4mENHKTH2tWz LvZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683242399; x=1685834399; h=content-transfer-encoding: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=jleM9mam0jC92K7s5TbbM7NijY+miJheeAbD3LOvDfA=; b=MglD6f/AUQQDhjGieFNbgmYnCIgvVDN+98EYjrvPr222qOkOayAN0TfhLWPmobrhiQ 3nrQYSoEsoVXJiWgDjcoFT4791MqEt7d7M+aNH2MSMUFuJoLNMaWUsDSNx5QXMNYdrGF I8bRpMA5D1pHa3Dvt7G1BxwNc3pHzjo1Y2tvig6hxKDcxior6Bf3fNPeG9kssKIYR9jb 1+OFDFEyeOlALlMdhMOWVjr3221wW4Y1Sy6/nc0jt6hZh/Asv+so17TbzP2aatw7ahP8 LNH36vDI/eYxOWR5KEelQzEGOifDipIMfZhXzZVzoVXLdgiZH9nF7YgCWCH9TAvFCH5Q QAuA== X-Gm-Message-State: AC+VfDxzG2OaO0fkC+7wureVYb6LClm1uQgP/bu1IiF4Via28M6PVLwQ KuJ7ZeaDEVl8g5/Kheg/oOztzVLlYUVdj9GuTvR3ww== X-Received: by 2002:a92:cdac:0:b0:32a:dc6a:3b97 with SMTP id g12-20020a92cdac000000b0032adc6a3b97mr10344ild.0.1683242398875; Thu, 04 May 2023 16:19:58 -0700 (PDT) MIME-Version: 1.0 References: <20230503211801.897735-1-acme@kernel.org> In-Reply-To: From: Ian Rogers Date: Thu, 4 May 2023 16:19:47 -0700 Message-ID: Subject: Re: BPF skels in perf .Re: [GIT PULL] perf tools changes for v6.4 To: Jiri Olsa Cc: Arnaldo Carvalho de Melo , Andrii Nakryiko , Namhyung Kim , Linus Torvalds , Song Liu , Andrii Nakryiko , Ingo Molnar , Thomas Gleixner , Clark Williams , Kate Carcia , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Adrian Hunter , Changbin Du , Hao Luo , James Clark , Kan Liang , Roman Lozko , Stephane Eranian , Thomas Richter , Arnaldo Carvalho de Melo , bpf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED,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 Thu, May 4, 2023 at 4:03=E2=80=AFPM Jiri Olsa wrote= : > > On Thu, May 04, 2023 at 03:03:42PM -0700, Ian Rogers wrote: > > On Thu, May 4, 2023 at 2:48=E2=80=AFPM Arnaldo Carvalho de Melo wrote: > > > > > > Em Thu, May 04, 2023 at 04:07:29PM -0300, Arnaldo Carvalho de Melo es= creveu: > > > > Em Thu, May 04, 2023 at 11:50:07AM -0700, Andrii Nakryiko escreveu: > > > > > On Thu, May 4, 2023 at 10:52=E2=80=AFAM Arnaldo Carvalho de Melo = wrote: > > > > > > Andrii, can you add some more information about the usage of vm= linux.h > > > > > > instead of using kernel headers? > > > > > > > > > I'll just say that vmlinux.h is not a hard requirement to build B= PF > > > > > programs, it's more a convenience allowing easy access to definit= ions > > > > > of both UAPI and kernel-internal structures for tracing needs and > > > > > marking them relocatable using BPF CO-RE machinery. Lots of real-= world > > > > > applications just check-in pregenerated vmlinux.h to avoid build-= time > > > > > dependency on up-to-date host kernel and such. > > > > > > > > > If vmlinux.h generation and usage is causing issues, though, give= n > > > > > that perf's BPF programs don't seem to be using many different ke= rnel > > > > > types, it might be a better option to just use UAPI headers for p= ublic > > > > > kernel type definitions, and just define CO-RE-relocatable minima= l > > > > > definitions locally in perf's BPF code for the other types necess= ary. > > > > > E.g., if perf needs only pid and tgid from task_struct, this woul= d > > > > > suffice: > > > > > > > > > struct task_struct { > > > > > int pid; > > > > > int tgid; > > > > > } __attribute__((preserve_access_index)); > > > > > > > > Yeah, that seems like a way better approach, no vmlinux involved, l= ibbpf > > > > CO-RE notices that task_struct changed from this two integers versi= on > > > > (of course) and does the relocation to where it is in the running k= ernel > > > > by using /sys/kernel/btf/vmlinux. > > > > > > Doing it for one of the skels, build tested, runtime untested, but no= t > > > using any vmlinux, BTF to help, not that bad, more verbose, but at le= ast > > > we state what are the fields we actually use, have those attribute > > > documenting that those offsets will be recorded for future use, etc. > > > > > > Namhyung, can you please check that this works? > > > > > > Thanks, > > > > > > - Arnaldo > > > > > > diff --git a/tools/perf/util/bpf_skel/bperf_cgroup.bpf.c b/tools/perf= /util/bpf_skel/bperf_cgroup.bpf.c > > > index 6a438e0102c5a2cb..f376d162549ebd74 100644 > > > --- a/tools/perf/util/bpf_skel/bperf_cgroup.bpf.c > > > +++ b/tools/perf/util/bpf_skel/bperf_cgroup.bpf.c > > > @@ -1,11 +1,40 @@ > > > // SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > // Copyright (c) 2021 Facebook > > > // Copyright (c) 2021 Google > > > -#include "vmlinux.h" > > > +#include > > > +#include > > > > Compared to vmlinux.h here be dragons. It is easy to start dragging in > > all of libc and that may not work due to missing #ifdefs, etc.. Could > > we check in a vmlinux.h like libbpf-tools does? > > https://github.com/iovisor/bcc/tree/master/libbpf-tools#vmlinuxh-genera= tion > > https://github.com/iovisor/bcc/tree/master/libbpf-tools/arm64 > > > > This would also remove some of the errors that could be introduced by > > copy+pasting enums, etc. and also highlight issues with things being > > renamed as build time rather than runtime failures. > > we already have to deal with that, right? doing checks on fields in > structs like mm_struct___old We do, but the way I detected the problems in the first place was by building against older kernels. Now the build will always succeed but fail at runtime. > > Could this be some shared resource for the different linux tools > > projects using a vmlinux.h? e.g. tools/lib/vmlinuxh with an > > install_headers target that builds a vmlinux.h. > > I tried to do the minimal header and it's not too big, > I pushed it in here: > https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git/log/?h= =3Dperf/vmlinux_h > > compile tested so far > > jirka Cool, could we just call it vmlinux.h rather than perf-defs.h? I notice cgroup_subsys_id is in there which is called out in Andrii's CO-RE guide/blog: https://nakryiko.com/posts/bpf-core-reference-guide/#relocatable-enums perhaps we can do something with names/types to make sure a helper is being used for these enum values. Thanks, Ian