From patchwork Fri Jun 10 11:26:47 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Quentin Monnet X-Patchwork-Id: 12877494 X-Patchwork-Delegate: bpf@iogearbox.net 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BB734C433EF for ; Fri, 10 Jun 2022 11:27:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244645AbiFJL1C (ORCPT ); Fri, 10 Jun 2022 07:27:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244938AbiFJL1A (ORCPT ); Fri, 10 Jun 2022 07:27:00 -0400 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0260422AE54 for ; Fri, 10 Jun 2022 04:26:54 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id k16so36124688wrg.7 for ; Fri, 10 Jun 2022 04:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isovalent-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=z6pm2qCe57m4cj/i6Nw8fuyY87mpFyZBWCzSGpujiLA=; b=lms9GXo5N9JJ11khW/qYk7zkpRchFwIzIneT5oYb7D1yIp0BYYK5QLRsgQ0j4HiHAI BlIuWRGd7f/ZBQqG1gW/Pfha8G+chJZYmXR2h0Cxfbzn2RcVqLoiopS2AULTpvreqQ2m qM6bIuXSU+HqcRVTQkwCTlHU3U6MfhhQcq5ZocKMB7oyGEqgJeALKLxRyugMCVDFD5Mc BrvRcpD39NB4R3QOPnNmAQCZoR3fB/jjQXSu7jJsqgmWA+zwKOk3yVkyz6yCFEM7SNQ+ xX4dabswsxc3v6gE2HLwLCCb7L8eJaSUGyy+QlZUWmZvH0HX4Dh8G3hOsPsYCHME7lqw tmrA== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=z6pm2qCe57m4cj/i6Nw8fuyY87mpFyZBWCzSGpujiLA=; b=6MIexgtLKNnZTGwzwheSzbFMcJvH2CCkMAzeQouLiebscrA9RwBoPizgKfwaXT1IHA 6YhClpniJF7+hVD8Gt2Z8Udo2lBkPk67VxHmqJiOmE7Feo+jYrqOjHkv7p0o0LugAzaC h0ZSfsuTqjMuFUl6ye5iAlG7vZOIlYdP6Dv2AJOtpHm7WD8BoUQgKJZUjyfjb7cx2x4s jJnQL88A9IhoGSR23ER3VVNWNGmuqiHrM7GRL/FO+QyXhDZDVhpBLJLkkJ/SCem9YSU1 2Q8R6uTirGY53obIvt8d6TyxQjTOFR4rBu+8/8faKMEoGL5drKIkH6D4r+OBkAly+OxG Hw+w== X-Gm-Message-State: AOAM532bB/E3sF+gUg9FriBK+tX8SqduGTlkArRKFe2f7DmxteWiUZEZ GC8uTM6/ZGnzxamfC8rKyLDqZ3xwdUpT7cSAOiU= X-Google-Smtp-Source: ABdhPJzSw/2MhXzYSoxgWqS7s/ttSDfOsMI+GVLnDda/7tKR+QcViqT6OquUpH9+OtgviLweWVn8sg== X-Received: by 2002:a5d:56d2:0:b0:212:9250:e18b with SMTP id m18-20020a5d56d2000000b002129250e18bmr41608173wrw.672.1654860413254; Fri, 10 Jun 2022 04:26:53 -0700 (PDT) Received: from harfang.fritz.box ([51.155.200.13]) by smtp.gmail.com with ESMTPSA id z2-20020adff1c2000000b0020c5253d8dcsm25893202wro.40.2022.06.10.04.26.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jun 2022 04:26:52 -0700 (PDT) From: Quentin Monnet To: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko Cc: Yafang Shao , Harsh Modi , Paul Chaignon , netdev@vger.kernel.org, bpf@vger.kernel.org, Quentin Monnet Subject: [PATCH bpf-next 1/2] Revert "bpftool: Use libbpf 1.0 API mode instead of RLIMIT_MEMLOCK" Date: Fri, 10 Jun 2022 12:26:47 +0100 Message-Id: <20220610112648.29695-2-quentin@isovalent.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220610112648.29695-1-quentin@isovalent.com> References: <20220610112648.29695-1-quentin@isovalent.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: bpf@iogearbox.net This reverts commit a777e18f1bcd32528ff5dfd10a6629b655b05eb8. In commit a777e18f1bcd ("bpftool: Use libbpf 1.0 API mode instead of RLIMIT_MEMLOCK"), we removed the rlimit bump in bpftool, because the kernel has switched to memcg-based memory accounting. Thanks to the LIBBPF_STRICT_AUTO_RLIMIT_MEMLOCK, we attempted to keep compatibility with other systems and ask libbpf to raise the limit for us if necessary. How do we know if memcg-based accounting is supported? There is a probe in libbpf to check this. But this probe currently relies on the availability of a given BPF helper, bpf_ktime_get_coarse_ns(), which landed in the same kernel version as the memory accounting change. This works in the generic case, but it may fail, for example, if the helper function has been backported to an older kernel. This has been observed for Google Cloud's Container-Optimized OS (COS), where the helper is available but rlimit is still in use. The probe succeeds, the rlimit is not raised, and probing features with bpftool, for example, fails. A patch was submitted [0] to update this probe in libbpf, based on what the cilium/ebpf Go library does [1]. It would lower the soft rlimit to 0, attempt to load a BPF object, and reset the rlimit. But it may induce some hard-to-debug flakiness if another process starts, or the current application is killed, while the rlimit is reduced, and the approach was discarded. As a workaround to ensure that the rlimit bump does not depend on the availability of a given helper, we restore the unconditional rlimit bump in bpftool for now. [0] https://lore.kernel.org/bpf/20220609143614.97837-1-quentin@isovalent.com/ [1] https://github.com/cilium/ebpf/blob/v0.9.0/rlimit/rlimit.go#L39 Cc: Yafang Shao Signed-off-by: Quentin Monnet --- tools/bpf/bpftool/common.c | 8 ++++++++ tools/bpf/bpftool/feature.c | 2 ++ tools/bpf/bpftool/main.c | 6 +++--- tools/bpf/bpftool/main.h | 2 ++ tools/bpf/bpftool/map.c | 2 ++ tools/bpf/bpftool/pids.c | 1 + tools/bpf/bpftool/prog.c | 3 +++ tools/bpf/bpftool/struct_ops.c | 2 ++ 8 files changed, 23 insertions(+), 3 deletions(-) diff --git a/tools/bpf/bpftool/common.c b/tools/bpf/bpftool/common.c index a45b42ee8ab0..a0d4acd7c54a 100644 --- a/tools/bpf/bpftool/common.c +++ b/tools/bpf/bpftool/common.c @@ -17,6 +17,7 @@ #include #include #include +#include #include #include @@ -72,6 +73,13 @@ static bool is_bpffs(char *path) return (unsigned long)st_fs.f_type == BPF_FS_MAGIC; } +void set_max_rlimit(void) +{ + struct rlimit rinf = { RLIM_INFINITY, RLIM_INFINITY }; + + setrlimit(RLIMIT_MEMLOCK, &rinf); +} + static int mnt_fs(const char *target, const char *type, char *buff, size_t bufflen) { diff --git a/tools/bpf/bpftool/feature.c b/tools/bpf/bpftool/feature.c index cc9e4df8c58e..bac4ef428a02 100644 --- a/tools/bpf/bpftool/feature.c +++ b/tools/bpf/bpftool/feature.c @@ -1167,6 +1167,8 @@ static int do_probe(int argc, char **argv) __u32 ifindex = 0; char *ifname; + set_max_rlimit(); + while (argc) { if (is_prefix(*argv, "kernel")) { if (target != COMPONENT_UNSPEC) { diff --git a/tools/bpf/bpftool/main.c b/tools/bpf/bpftool/main.c index 9062ef2b8767..e81227761f5d 100644 --- a/tools/bpf/bpftool/main.c +++ b/tools/bpf/bpftool/main.c @@ -507,9 +507,9 @@ int main(int argc, char **argv) * It will still be rejected if users use LIBBPF_STRICT_ALL * mode for loading generated skeleton. */ - libbpf_set_strict_mode(LIBBPF_STRICT_ALL & ~LIBBPF_STRICT_MAP_DEFINITIONS); - } else { - libbpf_set_strict_mode(LIBBPF_STRICT_AUTO_RLIMIT_MEMLOCK); + ret = libbpf_set_strict_mode(LIBBPF_STRICT_ALL & ~LIBBPF_STRICT_MAP_DEFINITIONS); + if (ret) + p_err("failed to enable libbpf strict mode: %d", ret); } argc -= optind; diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h index 6c311f47147e..589cb76b227a 100644 --- a/tools/bpf/bpftool/main.h +++ b/tools/bpf/bpftool/main.h @@ -96,6 +96,8 @@ int detect_common_prefix(const char *arg, ...); void fprint_hex(FILE *f, void *arg, unsigned int n, const char *sep); void usage(void) __noreturn; +void set_max_rlimit(void); + int mount_tracefs(const char *target); struct obj_ref { diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c index 800834be1bcb..38b6bc9c26c3 100644 --- a/tools/bpf/bpftool/map.c +++ b/tools/bpf/bpftool/map.c @@ -1326,6 +1326,8 @@ static int do_create(int argc, char **argv) goto exit; } + set_max_rlimit(); + fd = bpf_map_create(map_type, map_name, key_size, value_size, max_entries, &attr); if (fd < 0) { p_err("map create failed: %s", strerror(errno)); diff --git a/tools/bpf/bpftool/pids.c b/tools/bpf/bpftool/pids.c index e2d00d3cd868..bb6c969a114a 100644 --- a/tools/bpf/bpftool/pids.c +++ b/tools/bpf/bpftool/pids.c @@ -108,6 +108,7 @@ int build_obj_refs_table(struct hashmap **map, enum bpf_obj_type type) p_err("failed to create hashmap for PID references"); return -1; } + set_max_rlimit(); skel = pid_iter_bpf__open(); if (!skel) { diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c index e71f0b2da50b..f081de398b60 100644 --- a/tools/bpf/bpftool/prog.c +++ b/tools/bpf/bpftool/prog.c @@ -1590,6 +1590,8 @@ static int load_with_options(int argc, char **argv, bool first_prog_only) } } + set_max_rlimit(); + if (verifier_logs) /* log_level1 + log_level2 + stats, but not stable UAPI */ open_opts.kernel_log_level = 1 + 2 + 4; @@ -2287,6 +2289,7 @@ static int do_profile(int argc, char **argv) } } + set_max_rlimit(); err = profiler_bpf__load(profile_obj); if (err) { p_err("failed to load profile_obj"); diff --git a/tools/bpf/bpftool/struct_ops.c b/tools/bpf/bpftool/struct_ops.c index 2535f079ed67..e08a6ff2866c 100644 --- a/tools/bpf/bpftool/struct_ops.c +++ b/tools/bpf/bpftool/struct_ops.c @@ -501,6 +501,8 @@ static int do_register(int argc, char **argv) if (libbpf_get_error(obj)) return -1; + set_max_rlimit(); + if (bpf_object__load(obj)) { bpf_object__close(obj); return -1; From patchwork Fri Jun 10 11:26:48 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Quentin Monnet X-Patchwork-Id: 12877493 X-Patchwork-Delegate: bpf@iogearbox.net 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8C3FCCA47C for ; Fri, 10 Jun 2022 11:27:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349308AbiFJL1E (ORCPT ); Fri, 10 Jun 2022 07:27:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35016 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233916AbiFJL1B (ORCPT ); Fri, 10 Jun 2022 07:27:01 -0400 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0E6722AE79 for ; Fri, 10 Jun 2022 04:26:55 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id z17so8920533wmi.1 for ; Fri, 10 Jun 2022 04:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isovalent-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=99g/H9hORM8QK7xT+vs5uD4GZTI6jZJp2du0cH8N2LY=; b=CahFhHENPeNQXpEJhMG/HPnrrccC9bgyah6cccG6vgwSE915ECBBpsIXn6eqxe4vI1 WpyQtu9gN4B/KUb1Cg9jwk0zZeVl7qa7npP4lMxuH4W8/YmciMyFaovsL5293zcNPX5W NzCvKwmPePppGlIwC7o0v2qh4J0uGbxlIJRh2vPUcPJ7yg9XDsNaup8PN9jmAL6hK9ZG Emm4YD4qg74WzLh8z8JSBKeFYzRNAtlWFHR0DfAD+w0zAE7XDq1yecFA20He00NMjR6+ b8gGzENOmBirp+8cyj+80T/ajyAP0DAwk3NR+iknORAvvcIVu7HK55r8aQfsEicdzpp5 eqqA== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=99g/H9hORM8QK7xT+vs5uD4GZTI6jZJp2du0cH8N2LY=; b=r1zU54fiASiPorsY5KGcqSOV10+9QaNBDYUSO7TyG4tenMKrwjJS+U5N/QEtotgxZ1 Bu0a+Bn1yTgF8Zzodma/aw9rYBlUp4SPAy9hnkaXEiZA2/jxad+zNV/LH/9pq8amQZkT uYEYvSKfZzjfPAHpTdl+YYglR/Fy4PxraayOZVdo/AD5cBar4lHtzUg0uxBxZrd4avyA YiwuiB9XESO9IWx25DdhXUoagjTu57d4LnWLcEmyQ697n/xX6txJET3qLdsIu0Dctlal ZJFnrfZUM1rsg7dDQZ7NUmNS/CZf+5cn4wgGKiFM7R8gCooi6ZQewLAiajKnlqbevbhe I+1A== X-Gm-Message-State: AOAM533TozQLB4SE/04rElJa4OKOg9WATvBuAx63QnS46JoEutFBWSmC Ml6jtSuHvfP1LOAvXy4KdkXxuQ== X-Google-Smtp-Source: ABdhPJwsBI+YOWDl8NwJJiNoTpF+Lg6pJpL8aeP2+035r6YnNJ39PCfteQ1I7oOJKsToTdzUqjqa8Q== X-Received: by 2002:a05:600c:35c1:b0:39c:7930:7b5b with SMTP id r1-20020a05600c35c100b0039c79307b5bmr4744956wmq.162.1654860414169; Fri, 10 Jun 2022 04:26:54 -0700 (PDT) Received: from harfang.fritz.box ([51.155.200.13]) by smtp.gmail.com with ESMTPSA id z2-20020adff1c2000000b0020c5253d8dcsm25893202wro.40.2022.06.10.04.26.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jun 2022 04:26:53 -0700 (PDT) From: Quentin Monnet To: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko Cc: Yafang Shao , Harsh Modi , Paul Chaignon , netdev@vger.kernel.org, bpf@vger.kernel.org, Quentin Monnet Subject: [PATCH bpf-next 2/2] bpftool: Do not check return value from libbpf_set_strict_mode() Date: Fri, 10 Jun 2022 12:26:48 +0100 Message-Id: <20220610112648.29695-3-quentin@isovalent.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220610112648.29695-1-quentin@isovalent.com> References: <20220610112648.29695-1-quentin@isovalent.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: bpf@iogearbox.net The function always returns 0, so we don't need to check whether the return value is 0 or not. This change was first introduced in commit a777e18f1bcd ("bpftool: Use libbpf 1.0 API mode instead of RLIMIT_MEMLOCK"), but later reverted to restore the unconditional rlimit bump in bpftool. Let's re-add it. Co-developed-by: Yafang Shao Signed-off-by: Quentin Monnet --- tools/bpf/bpftool/main.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/tools/bpf/bpftool/main.c b/tools/bpf/bpftool/main.c index e81227761f5d..451cefc2d0da 100644 --- a/tools/bpf/bpftool/main.c +++ b/tools/bpf/bpftool/main.c @@ -507,9 +507,7 @@ int main(int argc, char **argv) * It will still be rejected if users use LIBBPF_STRICT_ALL * mode for loading generated skeleton. */ - ret = libbpf_set_strict_mode(LIBBPF_STRICT_ALL & ~LIBBPF_STRICT_MAP_DEFINITIONS); - if (ret) - p_err("failed to enable libbpf strict mode: %d", ret); + libbpf_set_strict_mode(LIBBPF_STRICT_ALL & ~LIBBPF_STRICT_MAP_DEFINITIONS); } argc -= optind;