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.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 19141C4360C for ; Sat, 12 Oct 2019 04:38:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D1D56206CD for ; Sat, 12 Oct 2019 04:38:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="b/V+Eh3i" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726407AbfJLEiT (ORCPT ); Sat, 12 Oct 2019 00:38:19 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:46494 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726269AbfJLEiT (ORCPT ); Sat, 12 Oct 2019 00:38:19 -0400 Received: by mail-qt1-f196.google.com with SMTP id u22so16934926qtq.13; Fri, 11 Oct 2019 21:38:18 -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=TUKns7wuiKOPhZOksi8rGoNGy3wniKVMz8Gwo1AYhA4=; b=b/V+Eh3i3QF8FXzCfkOulJHgZj1exG1MgY//Id1GC1AduYVi3koPCuZV90TA+yI4RD 1xwsNTzMASDsTMzZpUiITJk5HJ6oUxT9PHnWIKcDAYRqrKZSMs3zzPb+AEu06lW6COxq rwoqW2zhVo63M9YuvgAxkTmyzYLKj+/bQRNAM2pnMr46aFSlQa3buQNae+7NDB9X8rdS 9qajGwKIbC23Xbu0wVhdB/ax103O/MyULm2aeHybGcxdTv9N+CCDsGK18YkZJrT+WZat DhRMkasrPZye/vNMGIWGlASIoOUnaYvfDuMxIHjEEOHgKtLTxb8yhbOOz/vfJmBUuUcA 0d2w== 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=TUKns7wuiKOPhZOksi8rGoNGy3wniKVMz8Gwo1AYhA4=; b=Olz+b5fnEow5k8BfhAjVrvG6mDsM9QOgi2/hhDqqOYMVMVwIbio8EETC4Z3ka5L6IV Y6j4vy2v+bcMbeEsle3FtLHeL+h/QZPO2zCSej9wVCyFEYKl+R2YEBM3EffR+WEYO5tm rFWggfWsr92CtHbXZLODKsqNREvDbbL+SaTrqJL8AbipahBL8FIUVes1PbT8dowG7pK9 57nsCAAcPAtkGxu09L7M/UIchecMYXnDRNnhwvkrB0CEVzeN7oFxhjhFaz4PEHLc6a5E ldLC9CVZQ0h6UNXrVyDrlLredCm0Vam1nby7z0pINvestL9Z12oHGFZKzejSfYFS7Wcc adCg== X-Gm-Message-State: APjAAAXSH0iHlVghYEBM3xHPPk3gXOyagcT5VTcNsyUJzCL/D8FSDGKs Bb/bkMA2ySBomCczxZZaPc9XDYe4n9Ca++AJJOg= X-Google-Smtp-Source: APXvYqzriVCzHruUq0dInxh/hj2C7wisIpTxHvfPsQZbHokbFCBBDvMeNVjp0sZBXxK7g3R1xtEhdBNugG71FeqvBUM= X-Received: by 2002:a0c:f885:: with SMTP id u5mr19355583qvn.247.1570855097834; Fri, 11 Oct 2019 21:38:17 -0700 (PDT) MIME-Version: 1.0 References: <20191010041503.2526303-1-ast@kernel.org> <20191010041503.2526303-6-ast@kernel.org> <0dbf83e8-10ec-cc17-c575-949639a7f018@fb.com> In-Reply-To: From: Andrii Nakryiko Date: Fri, 11 Oct 2019 21:38:06 -0700 Message-ID: Subject: Re: [PATCH v2 bpf-next 05/12] libbpf: auto-detect btf_id of raw_tracepoint To: Alexei Starovoitov Cc: Alexei Starovoitov , "David S. Miller" , Daniel Borkmann , "x86@kernel.org" , Networking , bpf , Kernel Team 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, Oct 11, 2019 at 6:29 PM Alexei Starovoitov wrote: > > On 10/11/19 5:40 PM, Alexei Starovoitov wrote: > >> But even if kernel supports attach_btf_id, I think users still need to > >> opt in into specifying attach_btf_id by libbpf. Think about existing > >> raw_tp programs that are using bpf_probe_read() because they were not > >> created with this kernel feature in mind. They will suddenly stop > >> working without any of user's fault. > > > > This one is excellent catch. > > loop1.c should have caught it, since it has > > SEC("raw_tracepoint/kfree_skb") > > { > > int nested_loops(volatile struct pt_regs* ctx) > > .. = PT_REGS_RC(ctx); > > > > and verifier would have rejected it. > > But the way the test is written it's not using libbpf's autodetect > > of program type, so everything is passing. > > With: > diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c > b/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c > index 1c01ee2600a9..e27156dce10d 100644 > --- a/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c > +++ b/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c > @@ -67,7 +67,7 @@ void test_bpf_verif_scale(void) > */ > { "pyperf600_nounroll.o", BPF_PROG_TYPE_RAW_TRACEPOINT }, > > - { "loop1.o", BPF_PROG_TYPE_RAW_TRACEPOINT }, > + { "loop1.o", BPF_PROG_TYPE_UNSPEC}, > { "loop2.o", BPF_PROG_TYPE_RAW_TRACEPOINT }, > > libbpf prog auto-detection kicks in and ... > # ./test_progs -n 3/10 > libbpf: load bpf program failed: Permission denied > libbpf: -- BEGIN DUMP LOG --- > libbpf: > raw_tp 'kfree_skb' doesn't have 10-th argument > invalid bpf_context access off=80 size=8 > > Good :) The verifier is doing its job. oh, another super intuitive error from verifier ;) 10th argument, what?..