From patchwork Thu Nov 22 06:03:03 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Nikita V. Shirokov" X-Patchwork-Id: 1001550 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=tehnerd.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=tehnerd-com.20150623.gappssmtp.com header.i=@tehnerd-com.20150623.gappssmtp.com header.b="MqdwQnu+"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 430pm3168Sz9s0t for ; Thu, 22 Nov 2018 17:03:46 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404625AbeKVQlQ (ORCPT ); Thu, 22 Nov 2018 11:41:16 -0500 Received: from mail-it1-f194.google.com ([209.85.166.194]:54333 "EHLO mail-it1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731512AbeKVQlQ (ORCPT ); Thu, 22 Nov 2018 11:41:16 -0500 Received: by mail-it1-f194.google.com with SMTP id a205-v6so12506808itd.4 for ; Wed, 21 Nov 2018 22:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tehnerd-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=sknfCNgyKIbmVGJ0scwS11rB23OHTN0dV6MD3JvGaDg=; b=MqdwQnu+ewFK55AtJQks2BCageE+YWYvBPpnLKBRa9u9ieA3A4E4/UAXCWsV7OU0Mu Nf9hE0xYfHaAq59c6Q9hM1YZMWinZ0smtJDB1oZdKq/oN2kM4lG6Lsm4DBPGEni7w7CS Q7qs5FXyk5HVqV/m5W/bhf9MbshTRyrNkwFNwfiO5adCqfQoVyslUq4gHVPdwbtU3WGq EqVNdoCAHXDjhdmXvRQUvOTRagNuJsSxHl4gneiy9D0q9QBspLHTYSgbOmdZ2KZYuRpR r5K8tgAqmkKLApRk9qqA89lmOUnfsFfPRr30TscePbbjg5dwcFFiefEHkVbiJSzNGr98 gGQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=sknfCNgyKIbmVGJ0scwS11rB23OHTN0dV6MD3JvGaDg=; b=P0FGzHSzfaRrea3Ax4VekxrrBy0NDOgEh8cZUs0TTBNnV79bitYo5d+GmFA/YUcYNS VFTlWMpTIvfv1rDGgCBgog0kxX7imVQh05M55D5phU20/jRxDYYIEN0rUfY5YN3o815j /2mqD/HYQWhNO2P+M3xCrJytVhoSaD9kYQHsO1U6HUBGqCvwSbJY9PIBUYxMJxLPEeuR 2MwsKeWqHGwLJQbAjOh+MhGr2/SsckBGxJoPHn0ILjt71gkWsUVDsVs2FUr0bT8WLOz6 qiWshBYI57aDTD0kSAEv9H5Y6cesZC+vZwbjllWLlm64LayOrSiX0SBLzx8YNAUiyTCH Mulg== X-Gm-Message-State: AA+aEWbpfRbvOgJYs5HYRFCqs2ySg7g0Ik2RrzdaGEmBb46Em63Ks7pk IUJAI1wtNdUYWpfpJCHVoTaWgQ== X-Google-Smtp-Source: AJdET5cybWZnKYtv1YBaCXxr7rTQqrqmB545kXeWcU3M/zCtstDa5Ep1yoJREwy8sK09tXo4cvumFQ== X-Received: by 2002:a24:f609:: with SMTP id u9mr9475062ith.116.1542866603022; Wed, 21 Nov 2018 22:03:23 -0800 (PST) Received: from maindev.thefacebook.com ([199.201.64.4]) by smtp.gmail.com with ESMTPSA id k133-v6sm1214983itb.16.2018.11.21.22.03.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 22:03:22 -0800 (PST) From: "Nikita V. Shirokov" To: Alexei Starovoitov , Daniel Borkmann Cc: netdev@vger.kernel.org, "Nikita V. Shirokov" Subject: [RFC PATCH bpf-next] libbpf: make bpf_object__open default to UNSPEC Date: Wed, 21 Nov 2018 22:03:03 -0800 Message-Id: <20181122060303.22143-1-tehnerd@tehnerd.com> X-Mailer: git-send-email 2.15.1 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org currently by default libbpf's bpf_object__open requires bpf's program to specify version in a code because of two things: 1) default prog type is set to KPROBE 2) KPROBE requires (in kernel/bpf/syscall.c) version to be specified in this RFC i'm proposing change default to UNSPEC and also changing logic of libbpf that it would reflect what we have today in kernel (aka only KPROBE type requires for version to be explicitly set). reason for change: currently only libbpf requires by default version to be explicitly set. it would be really hard for mainteiners of other custom bpf loaders to migrate to libbpf (as they dont control user's code and migration to the new loader (libbpf) wont be transparent for end user). what is going to be broken after this change: if someone were relying on default to be KPROBE for bpf_object__open his code will stop to work. however i'm really doubtfull that anyone is using this for kprobe type of programs (instead of, say, bcc or other tracing frameworks) other possible solutions (for discussion, would require more machinery): add another function like bpf_object__open w/ default to unspec Signed-off-by: Nikita V. Shirokov --- tools/lib/bpf/libbpf.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c index 0f14f7c074c2..ed4212a4c5f9 100644 --- a/tools/lib/bpf/libbpf.c +++ b/tools/lib/bpf/libbpf.c @@ -333,7 +333,7 @@ bpf_program__init(void *data, size_t size, char *section_name, int idx, prog->idx = idx; prog->instances.fds = NULL; prog->instances.nr = -1; - prog->type = BPF_PROG_TYPE_KPROBE; + prog->type = BPF_PROG_TYPE_UNSPEC; prog->btf_fd = -1; return 0; @@ -1649,12 +1649,12 @@ static bool bpf_prog_type__needs_kver(enum bpf_prog_type type) case BPF_PROG_TYPE_LIRC_MODE2: case BPF_PROG_TYPE_SK_REUSEPORT: case BPF_PROG_TYPE_FLOW_DISSECTOR: - return false; case BPF_PROG_TYPE_UNSPEC: - case BPF_PROG_TYPE_KPROBE: case BPF_PROG_TYPE_TRACEPOINT: - case BPF_PROG_TYPE_PERF_EVENT: case BPF_PROG_TYPE_RAW_TRACEPOINT: + case BPF_PROG_TYPE_PERF_EVENT: + return false; + case BPF_PROG_TYPE_KPROBE: default: return true; }