From patchwork Thu Oct 14 14:34:24 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lorenz Bauer X-Patchwork-Id: 12558677 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F9F9C433F5 for ; Thu, 14 Oct 2021 14:34:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7613B60EE5 for ; Thu, 14 Oct 2021 14:34:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230032AbhJNOhB (ORCPT ); Thu, 14 Oct 2021 10:37:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41462 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229994AbhJNOhA (ORCPT ); Thu, 14 Oct 2021 10:37:00 -0400 Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC55DC061570 for ; Thu, 14 Oct 2021 07:34:55 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id r18so20221427wrg.6 for ; Thu, 14 Oct 2021 07:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=6u++N1GZS21Vq5pEOOIw8ZH2pt4bmbuLIdHwwW27yCY=; b=s5JKieKymeUfajqBsRxGAOmQf6B1+XlttTvHMeNP3lfs1xu3R1pvUnro9uOUPxbhJ8 MQhYFa5QiIqOkdfiXzEwBfrooFfA638Ka5QooywckRgixvset6DSjgZF54152/lvqjSm o2zyH07AzOgyCy//a8wD0uWVvPiwY0H7bCqCE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=6u++N1GZS21Vq5pEOOIw8ZH2pt4bmbuLIdHwwW27yCY=; b=cztxHDWBdgvgLEASdLPBQKN6RFD0TksR7yJx7Wne5R3TsqDI6auT5KfaHprJtl42PA BMYsSevZYks8j7/mx2bqrG66wO6VsyNV7ssBmCdUmhycHt/AkKcUXaAK6C2xKUrzTLOW oijeCxY8rKUB97Pkr9sJ51DWPRBL6KEOPZjENgcuK9+Sqy/1OLiS1wL8PxPLL/6p81Hc KXlYeJs+nKz4BL2lIEjr2mOYWAAdicNmR8UmO9HhHlgsuqUm5K5NWQ/Fh2kI+GHZK4XR OGSGouPJOqw339IZXSJZ2Z0F2liqhExw3HRg+9/sMDHJ3QRs8Ic4pl2Evm4Xi3JAFi8o csqQ== X-Gm-Message-State: AOAM5321QUeNZRrEcZsO0TTWoOB77HiKq8VKm3R3wOu73HZ/Ufmc/PMR bxuKiMZusEQIvZpWQmlFHzByJA== X-Google-Smtp-Source: ABdhPJyIMCFdyR4NOw1RHZLH4GTd1eQFsOub0w1B+oj8+iSmAWYesz9QadEO9PbXyMaaVd8kvznNRQ== X-Received: by 2002:a05:600c:414c:: with SMTP id h12mr6174517wmm.66.1634222094561; Thu, 14 Oct 2021 07:34:54 -0700 (PDT) Received: from antares.. (4.4.a.7.5.8.b.d.d.b.6.7.4.d.a.6.f.f.6.2.a.5.a.7.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:7a5a:26ff:6ad4:76bd:db85:7a44]) by smtp.gmail.com with ESMTPSA id k6sm2656439wri.83.2021.10.14.07.34.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Oct 2021 07:34:54 -0700 (PDT) From: Lorenz Bauer To: andrii@kernel.org, ast@kernel.org, daniel@iogearbox.net Cc: bpf@vger.kernel.org, kernel-team@cloudflare.com, Lorenz Bauer Subject: [RFC 0/9] uapi/bpf.h for robots Date: Thu, 14 Oct 2021 15:34:24 +0100 Message-Id: <20211014143436.54470-1-lmb@cloudflare.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org X-Patchwork-State: RFC Hi, I recently presented at LPC 2021 [1] on problems I encountered when generating bindings from bpf.h. I proposed the following changes: * Use enums instead of macros * Use __bpf_md_ptr throughout * Give types / fields in bpf_attr a name * Have one bpf_attr field per bpf_cmd As David Miller pointed out, changing a macro definition to an enum is a breaking change if users use the C preprocessor for conditional compilation. Andrii has made a similar change in commit 1aae4bdd7879 ("bpf: Switch BPF UAPI #define constants used from BPF program side to enums") where he simply converted to enum. I'm doing the same here. Next is using __bpf_md_ptr, which seems to work quite well. We can even add const qualifiers. A minor nit is that we have to give the unnamed field generated by __bpf_md_ptr a name, otherwise we can't refer to it on the kernel side to get a __user pointer. Is there a better way? If not, is there a better naming scheme? Giving types and fields a name in bpf_attr goes hand in hand with having one field per bpf_cmd in bpf_attr. This means that kernel-side code would become more verbose: int ufd = attr->map_fd; vs. int ufd = attr->map_create.map_fd; Not great. The solution I've prototyped is that we convert from bpf_attr to e.g. struct bpf_map_create_attr as early as possible. This is made easier by a new macro CHECK_ATTR_TAIL which allows us to remove the XXX_LAST_FIELD macros. There are a couple places where I cheat and cast back to union bpf_attr: in the real series more function signatures would need changing, which will cause a ripple effect. Finally, I convert one function in libbpf to use one of the new types to show what the changes look like from the libbpf side. It also ensures that all other syscall wrappers continue to compile unchanged. So, what does everyone think? 1: https://linuxplumbersconf.org/event/11/contributions/937/ Lorenz Bauer (9): bpf: name enums used from userspace bpf: various constants bpf: move up __bpf_md_ptr bpf: name __u64 member of __bpf_md_ptr bpf: introduce CHECK_ATTR_TAIL bpf: struct bpf_map_create_attr bpf: split map modification structs selftests: sync bpf.h libbpf: use new-style syscall args include/linux/bpf.h | 4 +- include/uapi/linux/bpf.h | 200 ++++++++++++++++++++++----------- kernel/bpf/syscall.c | 84 ++++++-------- tools/include/uapi/linux/bpf.h | 200 ++++++++++++++++++++++----------- tools/lib/bpf/bpf.c | 13 +-- 5 files changed, 309 insertions(+), 192 deletions(-)