From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC568C433DF for ; Fri, 19 Jun 2020 18:15:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9F78C2073E for ; Fri, 19 Jun 2020 18:15:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="kp6DN58m" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732226AbgFSSPk (ORCPT ); Fri, 19 Jun 2020 14:15:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57634 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731978AbgFSSPk (ORCPT ); Fri, 19 Jun 2020 14:15:40 -0400 Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AAF6FC06174E; Fri, 19 Jun 2020 11:15:39 -0700 (PDT) Received: by mail-qk1-x744.google.com with SMTP id q8so9784247qkm.12; Fri, 19 Jun 2020 11:15:39 -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=RYTTFB9vpBLIdJ5u4RqxHxQWqwi+IRzwIbFYmw2BZoo=; b=kp6DN58mQjYUlmrccU4+kTySQcS8a/C/2gnyYhsfvvJVNeMFr2O0Jo74HhMtd+HfyP 269DS2mt6wVSir99HUHhik1snmXpVTR2qo2F5OrQfxR6t40S5PEAoneeLD4QvzwdcKBM oRkgjS3kw8dutF2RY3K+cU9W/0fA89FnujPdkBStmXPURPG2Te9AosfOBKBIkKfH9ndt S5izn9ox8RjW/ZeC+jq4Wp13ZFS7g8twkYaNIUdwuLj2ReDXLwVrw1I4Ia32t5j+8tWx 2N+HnutCPq6VjwxLDwsxom6ylH7Nh9WNEZ5XxKMRWe9wSI0CSwb///ct6uDpTP4Q0rIi vCHQ== 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=RYTTFB9vpBLIdJ5u4RqxHxQWqwi+IRzwIbFYmw2BZoo=; b=AIRhYFnrQr1dCljv156N35r9VNg/ADFikozN6wVlBXvlFGb7yKOUYgfDbdKbYHP8BN hikBKIZb73+p1MzRn4+7D1zYeqTM0Chn7x4yRFWzr5AuqvaDAdzqDY0m4M+WSALpIUo3 2IHq8sJzexg9rJcKurYCGcrNWYmRhH7mqeKZCgHZIfmBDbAZtKUZ2hL1uZFxTgL/a1vY l4bMJZin9pXS6zyz6pyiM8gC42TvvMvl1nvyWw0/GYgOUs6UxZ8ZfHqMI9KG+0Y0ustj kLzcXnBTJOJnajg2rEkO5XVH2ShmvQAVTw1Km1mbRcSm6KIw6GtABE3mbdIQOJlQW00N SAMA== X-Gm-Message-State: AOAM5332CZPpOIE2CL9h3+PVQDS7FGYseQfaHpz9KQrOnYoIYJ/0ASDS RHcsspLIkH68aqzIksb81TIaGj1vVykIU4/wbEY= X-Google-Smtp-Source: ABdhPJxMG7Q9EcwgsIhFOnPt1WrO8kx/gLcbgmHTKrDahoF5DSRWAD6bFc5SXGogFT/UJuc/uxXT012OnFx0gDpIwTA= X-Received: by 2002:a37:6712:: with SMTP id b18mr4933834qkc.36.1592590538836; Fri, 19 Jun 2020 11:15:38 -0700 (PDT) MIME-Version: 1.0 References: <20200616100512.2168860-1-jolsa@kernel.org> <20200616100512.2168860-4-jolsa@kernel.org> <20200619131306.GD2465907@krava> In-Reply-To: <20200619131306.GD2465907@krava> From: Andrii Nakryiko Date: Fri, 19 Jun 2020 11:15:27 -0700 Message-ID: Subject: Re: [PATCH 03/11] bpf: Add btf_ids object To: Jiri Olsa Cc: Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Networking , bpf , Song Liu , Yonghong Song , Martin KaFai Lau , David Miller , John Fastabend , Wenbo Zhang , KP Singh , Andrii Nakryiko , Brendan Gregg , Florent Revest , Al Viro Content-Type: text/plain; charset="UTF-8" Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Fri, Jun 19, 2020 at 6:13 AM Jiri Olsa wrote: > > On Thu, Jun 18, 2020 at 05:56:38PM -0700, Andrii Nakryiko wrote: > > On Tue, Jun 16, 2020 at 3:05 AM Jiri Olsa wrote: > > > > > > Adding support to generate .BTF_ids section that would > > > hold various BTF IDs list for verifier. > > > > > > Adding macros help to define lists of BTF IDs placed in > > > .BTF_ids section. They are initially filled with zeros > > > (during compilation) and resolved later during the > > > linking phase by btfid tool. > > > > > > Following defines list of one BTF ID that is accessible > > > within kernel code as bpf_skb_output_btf_ids array. > > > > > > extern int bpf_skb_output_btf_ids[]; > > > > > > BTF_ID_LIST(bpf_skb_output_btf_ids) > > > BTF_ID(struct, sk_buff) > > > > > > Suggested-by: Andrii Nakryiko > > > Signed-off-by: Jiri Olsa > > > --- > > > include/asm-generic/vmlinux.lds.h | 4 ++ > > > kernel/bpf/Makefile | 2 +- > > > kernel/bpf/btf_ids.c | 3 ++ > > > kernel/bpf/btf_ids.h | 70 +++++++++++++++++++++++++++++++ > > > 4 files changed, 78 insertions(+), 1 deletion(-) > > > create mode 100644 kernel/bpf/btf_ids.c > > > create mode 100644 kernel/bpf/btf_ids.h > > > > > > > [...] > > > > > +/* > > > + * Following macros help to define lists of BTF IDs placed > > > + * in .BTF_ids section. They are initially filled with zeros > > > + * (during compilation) and resolved later during the > > > + * linking phase by btfid tool. > > > + * > > > + * Any change in list layout must be reflected in btfid > > > + * tool logic. > > > + */ > > > + > > > +#define SECTION ".BTF_ids" > > > > nit: SECTION is super generic and non-greppable. BTF_IDS_SECTION? > > ok > > > > > > + > > > +#define ____BTF_ID(symbol) \ > > > +asm( \ > > > +".pushsection " SECTION ",\"a\"; \n" \ > > > > section should be also read-only? Either immediately here, of btfid > > tool should mark it? Unless I missed that it's already doing it :) > > hm, it's there next to the .BTF section within RO_DATA macro, > so I thought that was enough.. I'll double check ah, linker script magic, got it > > > > > > +".local " #symbol " ; \n" \ > > > +".type " #symbol ", @object; \n" \ > > > +".size " #symbol ", 4; \n" \ > > > +#symbol ": \n" \ > > > +".zero 4 \n" \ > > > +".popsection; \n"); > > > + > > > +#define __BTF_ID(...) \ > > > + ____BTF_ID(__VA_ARGS__) > > > > why varargs, if it's always a single argument? Or it's one of those > > macro black magic things were it works only in this particular case, > > but not others? > > yea, I kind of struggled in here, because any other would not > expand the name concat together with the unique ID bit, > __VA_ARGS__ did it nicely ;-) I'll revisit this it's probably not varargs, but rather nested macro call. Macros are weird and tricky... > > thanks, > jirka >