From patchwork Thu Jan 16 07:44:41 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "D. Wythe" X-Patchwork-Id: 13941386 X-Patchwork-Delegate: bpf@iogearbox.net Received: from out30-98.freemail.mail.aliyun.com (out30-98.freemail.mail.aliyun.com [115.124.30.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15DF8192598; Thu, 16 Jan 2025 07:45:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.98 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737013503; cv=none; b=WJOyDhxc+cbpajBVnl99v/7YRZ6mvNfwt7ABBSPSHbxfuzMJy+73i99SF/tDquer9BQcq42ZJJK4TeVfX1grY5tfWIEGiJC38ASuTusRYrZBgihxHq5BfwhUzq3Uds0M3qCTzreDal2CLIc92StxIQVMINu0UBscDDAm9aEPIeY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737013503; c=relaxed/simple; bh=k+nSIYuMTE4Est9aRdXHeha1Cd9bQxNaTbZd3ettth4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Sa790Bjyi+MPUNfveoKoqkAYlqFkwrE+QPloEQt5VpLThNt5al3R/pmQus+MTfRP0QkZcCK6PxHk1jdfVrampzuj1O8Vebk3UKysHeu+l/RIUvFa6z6+nKHaTe3HCZdCabz1JFGLDl4zvMflemhq0Rijb0RBDCBPAuEJ5KdZJac= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=YxezVX1u; arc=none smtp.client-ip=115.124.30.98 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="YxezVX1u" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1737013493; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=dVUPfW9O39gAxRo2EWL64A14wdEsxYiVQQa/XAXiRjM=; b=YxezVX1ugIpTyvUri8LWDf7ecwWN7xY1JgkQ9NW60xwq3q8t2e54ttppuFodOoZuK3MDpYnKWhubCEeUW3VYXM5jbbieDAvFjpa61C8svTLeBLfj8xf5zv1x4DXk7SFAL/NxGqbeXi+7mZs+n/HWJh7UsA0CIqboq4dvIp7S1V0= Received: from j66a10360.sqa.eu95.tbsite.net(mailfrom:alibuda@linux.alibaba.com fp:SMTPD_---0WNkukXQ_1737013491 cluster:ay36) by smtp.aliyun-inc.com; Thu, 16 Jan 2025 15:44:51 +0800 From: "D. Wythe" To: kgraul@linux.ibm.com, wenjia@linux.ibm.com, jaka@linux.ibm.com, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, pabeni@redhat.com, song@kernel.org, sdf@google.com, haoluo@google.com, yhs@fb.com, edumazet@google.com, john.fastabend@gmail.com, kpsingh@kernel.org, jolsa@kernel.org, guwen@linux.alibaba.com Cc: kuba@kernel.org, davem@davemloft.net, netdev@vger.kernel.org, linux-s390@vger.kernel.org, linux-rdma@vger.kernel.org, bpf@vger.kernel.org Subject: [PATCH bpf-next v6 4/5] libbpf: fix error when st-prefix_ops and ops from differ btf Date: Thu, 16 Jan 2025 15:44:41 +0800 Message-ID: <20250116074442.79304-5-alibuda@linux.alibaba.com> X-Mailer: git-send-email 2.45.0 In-Reply-To: <20250116074442.79304-1-alibuda@linux.alibaba.com> References: <20250116074442.79304-1-alibuda@linux.alibaba.com> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: bpf@iogearbox.net When a struct_ops named xxx_ops was registered by a module, and it will be used in both built-in modules and the module itself, so that the btf_type of xxx_ops will be present in btf_vmlinux instead of in btf_mod, which means that the btf_type of bpf_struct_ops_xxx_ops and xxx_ops will not be in the same btf. Here are four possible case: +--------+---------------+-------------+---------------------------------+ | | st_ops_xxx_ops| xxx_ops | | +--------+---------------+-------------+---------------------------------+ | case 0 | btf_vmlinux | bft_vmlinux | be used and reg only in vmlinux | +--------+---------------+-------------+---------------------------------+ | case 1 | btf_vmlinux | bpf_mod | INVALID | +--------+---------------+-------------+---------------------------------+ | case 2 | btf_mod | btf_vmlinux | reg in mod but be used both in | | | | | vmlinux and mod. | +--------+---------------+-------------+---------------------------------+ | case 3 | btf_mod | btf_mod | be used and reg only in mod | +--------+---------------+-------------+---------------------------------+ At present, cases 0, 1, and 3 can be correctly identified, because st_ops_xxx_ops is searched from the same btf with xxx_ops. In order to handle case 2 correctly without affecting other cases, we cannot simply change the search method for st_ops_xxx_ops from find_btf_by_prefix_kind() to find_ksym_btf_id(), because in this way, case 1 will not be recognized anymore. To address the issue, we always look for st_ops_xxx_ops first, figure out the btf, and then look for xxx_ops with the very btf to avoid such issue. Fixes: 590a00888250 ("bpf: libbpf: Add STRUCT_OPS support") Signed-off-by: D. Wythe --- tools/lib/bpf/libbpf.c | 41 +++++++++++++++++++++++------------------ 1 file changed, 23 insertions(+), 18 deletions(-) diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c index 66173ddb5a2d..202bc4c1001e 100644 --- a/tools/lib/bpf/libbpf.c +++ b/tools/lib/bpf/libbpf.c @@ -1005,14 +1005,33 @@ find_struct_ops_kern_types(struct bpf_object *obj, const char *tname_raw, const struct btf_member *kern_data_member; struct btf *btf = NULL; __s32 kern_vtype_id, kern_type_id; - char tname[256]; + char tname[256], stname[256]; + int ret; __u32 i; snprintf(tname, sizeof(tname), "%.*s", (int)bpf_core_essential_name_len(tname_raw), tname_raw); - kern_type_id = find_ksym_btf_id(obj, tname, BTF_KIND_STRUCT, + ret = snprintf(stname, sizeof(stname), "%s%s", STRUCT_OPS_VALUE_PREFIX, + tname); + if (ret < 0 || ret >= sizeof(stname)) + return -ENAMETOOLONG; + + /* Look for the corresponding "map_value" type that will be used + * in map_update(BPF_MAP_TYPE_STRUCT_OPS) first, figure out the btf + * and the mod_btf. + * For example, find "struct bpf_struct_ops_tcp_congestion_ops". + */ + kern_vtype_id = find_ksym_btf_id(obj, stname, BTF_KIND_STRUCT, &btf, mod_btf); + if (kern_vtype_id < 0) { + pr_warn("struct_ops init_kern: struct %s is not found in kernel BTF\n", + stname); + return kern_vtype_id; + } + kern_vtype = btf__type_by_id(btf, kern_vtype_id); + + kern_type_id = btf__find_by_name_kind(btf, tname, BTF_KIND_STRUCT); if (kern_type_id < 0) { pr_warn("struct_ops init_kern: struct %s is not found in kernel BTF\n", tname); @@ -1020,20 +1039,6 @@ find_struct_ops_kern_types(struct bpf_object *obj, const char *tname_raw, } kern_type = btf__type_by_id(btf, kern_type_id); - /* Find the corresponding "map_value" type that will be used - * in map_update(BPF_MAP_TYPE_STRUCT_OPS). For example, - * find "struct bpf_struct_ops_tcp_congestion_ops" from the - * btf_vmlinux. - */ - kern_vtype_id = find_btf_by_prefix_kind(btf, STRUCT_OPS_VALUE_PREFIX, - tname, BTF_KIND_STRUCT); - if (kern_vtype_id < 0) { - pr_warn("struct_ops init_kern: struct %s%s is not found in kernel BTF\n", - STRUCT_OPS_VALUE_PREFIX, tname); - return kern_vtype_id; - } - kern_vtype = btf__type_by_id(btf, kern_vtype_id); - /* Find "struct tcp_congestion_ops" from * struct bpf_struct_ops_tcp_congestion_ops { * [ ... ] @@ -1046,8 +1051,8 @@ find_struct_ops_kern_types(struct bpf_object *obj, const char *tname_raw, break; } if (i == btf_vlen(kern_vtype)) { - pr_warn("struct_ops init_kern: struct %s data is not found in struct %s%s\n", - tname, STRUCT_OPS_VALUE_PREFIX, tname); + pr_warn("struct_ops init_kern: struct %s data is not found in struct %s\n", + tname, stname); return -EINVAL; }