From patchwork Wed Jul 15 21:43:10 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hao Luo X-Patchwork-Id: 11666323 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 160BA13B6 for ; Wed, 15 Jul 2020 21:43:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F13DF2078C for ; Wed, 15 Jul 2020 21:43:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="PvN9qtLW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726356AbgGOVnT (ORCPT ); Wed, 15 Jul 2020 17:43:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727094AbgGOVnT (ORCPT ); Wed, 15 Jul 2020 17:43:19 -0400 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C239AC08C5DB for ; Wed, 15 Jul 2020 14:43:18 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id x184so4601806ybx.10 for ; Wed, 15 Jul 2020 14:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=WPW2jthcymgJJnDe4srAy8GflGzwLl52ZFtIA0Ixzqw=; b=PvN9qtLWYSDsNHkgj/A27DsYxbLZ/Xnm+V0boSzvB8ey5BIexmosCy7fP6UkN8Zb4C sjRU/+R5zu11ex3BuKYJXCu8Ou4nJO1JBvDeL/VWYvR9Ex4e5VutdUb9RQCUUB8sYUag 2w+3i8jQdmRvbG9KhMIy39jcQELLbsG//2Iy5fj3qTFiC12LFmrkC3diSfvc5Yuxy/9F KtwNHAQwI/2lNQ+CS57Ti7gxaqePN96jkHJ039IoZCkJHRp1e/E5SdJmPZj6+/Kr/vMy 7T5pI1oyS6yTvXp3k+5+h5huvsrNOh7L4gpAnasiC27Ib9QLtf6R2tjZRCDElxuZLeOS 18uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=WPW2jthcymgJJnDe4srAy8GflGzwLl52ZFtIA0Ixzqw=; b=A4vX+xtpfGz1FhsHhU3R+4h5AFg4HRH8+VsgSB0gu2YgOmC1D6C7WRTGhA8cqNuFKb l+XA/2RZMFLeHgDl6Uz+ikNX/VB1cCuldinRzgPCzhFXG3s4OdVDQtfdG2rAkoodzb4H FssRfQXApV2qN2mZ00M+tBAF7p7yLt2SQ/5Z/EtPUNjnpNTWLIclceCFw51GPofW/35Y ZT6IcfzCQkcQM+HRh37350EvooaxdXD611JRd3sVFTdJOPbEVvjQCXht7+Dkxjv9thZL JWTlpdGUZJFsYxvO+SepgBhcZk8CW3jMG0BH5cglz+HiT8TQpr7o5xboBuWOuqMaQq8U qMBA== X-Gm-Message-State: AOAM531uJ6O4LZBKqjzBLmMaPEJue4TqPGY58Gkk5SmLSLZ/McdABl27 04QoXWWITySmtbbH+4pnSrSSa+ycuJo= X-Google-Smtp-Source: ABdhPJz/qTdRjOyD9NiyHcxQ5X4u25G5pK7DjjWbH8sfOQ6b1U0bIDyl+0KlG5qp/aUt1V0yHVOLYZN+VVE= X-Received: by 2002:a25:6c57:: with SMTP id h84mr1497780ybc.211.1594849397781; Wed, 15 Jul 2020 14:43:17 -0700 (PDT) Date: Wed, 15 Jul 2020 14:43:10 -0700 Message-Id: <20200715214312.2266839-1-haoluo@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.27.0.389.gc38d7665816-goog Subject: [RFC PATCH bpf-next 0/2] BTF support for ksyms From: Hao Luo To: netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Cc: Shuah Khan , Alexei Starovoitov , Andrii Nakryiko , John Fastabend , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , KP Singh , Stanislav Fomichev , Quentin Monnet , Hao Luo Sender: linux-kselftest-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org This patch series extends the previously add __ksym externs with btf info. Right now the __ksym externs are treated as pure 64-bit scalar value. Libbpf replaces ld_imm64 insn of __ksym by its kernel address at load time. This patch series extend those extern with their btf info. Note that btf support for __ksym must come with the btf that has VARs encoded to work properly. Therefore, these patches are tested against a btf generated by a patched pahole, whose change will available in released pahole soon. There are a couple of design choices that I would like feedbacks from bpf/btf experts. 1. Because the newly added pseudo_btf_id needs to carry both a kernel address (64 bits) and a btf id (32 bits), I used the 'off' fields of ld_imm insn to carry btf id. I wonder if this breaks anything or if there is a better idea. 2. Since only a subset of vars are going to be encoded into the new btf, if a ksym that doesn't find its btf id, it doesn't get converted into pseudo_btf_id. It is still treated as pure scalar value. But we require kernel btf to be loaded in libbpf if there is any ksym in the bpf prog. This is RFC as it requires pahole changes that encode kernel vars into btf. Hao Luo (2): bpf: BTF support for __ksym externs selftests/bpf: Test __ksym externs with BTF include/uapi/linux/bpf.h | 37 ++++++++++---- kernel/bpf/verifier.c | 26 ++++++++-- tools/include/uapi/linux/bpf.h | 37 ++++++++++---- tools/lib/bpf/libbpf.c | 50 ++++++++++++++++++- .../testing/selftests/bpf/prog_tests/ksyms.c | 2 + .../testing/selftests/bpf/progs/test_ksyms.c | 14 ++++++ 6 files changed, 143 insertions(+), 23 deletions(-)