Received: by 2002:a05:6358:f14:b0:e5:3b68:ec04 with SMTP id b20csp1475497rwj; Sun, 18 Dec 2022 08:56:03 -0800 (PST) X-Google-Smtp-Source: AA0mqf6cC2DsD4tOjuiC3V9d6s5Brz+vg/YNmCc1eoH1xt981DSGtnIcNicrGoaRyb4kaDxQyS9I X-Received: by 2002:a05:6402:299b:b0:468:fd17:aeb9 with SMTP id eq27-20020a056402299b00b00468fd17aeb9mr31168474edb.0.1671382563178; Sun, 18 Dec 2022 08:56:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671382563; cv=none; d=google.com; s=arc-20160816; b=LMEWce9ZnmrhwiTqxP8SqO+ObAmI6oqGlw3crhNps87l4W8rPVKYba02ynVPWz608S lpG4kEFJpcn02gjCvLpVgueIXgsUN++ZxvqIDGgSIac/krVa35iKVPMv7R5GWMFf1zNC IGmwZtkikrMkcsKMJmQ8VDUo9KXOV0wa4E/0Uz84cKWvftiNbnXMCbQ/tCggz3+Uv8PU c0OE55XKlT0sRxPE/QE9/q7lebSDpRiuwvdnoSfiJixZvybVDYcFaqBxEzsnQnm93Jvk ct8N2OSjviW0gCOSxXbVfvYQOBmtE4HjCPN0Z+FnfLNHJIH/XoRFXYXPMtoeVwZToAZQ lrKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=y1HiOuvSfOxg43epVh5xfkOLATfyk24nKWXWa2tuzmM=; b=ZLes8RpY59s1x6XMeQ3RVHg7sYBVMVhaOG0DfoVbLwr1DkwSTgqeBOXPXGh/82wGRk hZk88v6V7oKOUWP9BwqQo3GDlczftPbrTPJS7EMw9VxXIXlPrtM1608azCQE1xViyTmj VzsaDrTQ3ZO19zgTxiL//82kmfAx10MriXjbtXt6WIjQQh2V2AVXS0p0+dz/G+Tm45By JpRv0mtjNTUBd70PFVCkY9qcdOQ7Qt1ax4acFWeNaGNgUSecC+qMFv1KehRZ0BtvvTzS aPBsWwXvDWClrmqgdluZt3fv69yrP1EUvxOoXzjNVtdYgwcoPWcZoq8Slv4cM42IqFf4 j6UQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BDnwl28m; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id di17-20020a170906731100b007be1d7d1c3csi7906119ejc.386.2022.12.18.08.55.46; Sun, 18 Dec 2022 08:56:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BDnwl28m; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232674AbiLRQpG (ORCPT + 70 others); Sun, 18 Dec 2022 11:45:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43992 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232469AbiLRQoX (ORCPT ); Sun, 18 Dec 2022 11:44:23 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36207C32; Sun, 18 Dec 2022 08:15:44 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BB00FB80BA4; Sun, 18 Dec 2022 16:15:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B888BC433D2; Sun, 18 Dec 2022 16:15:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1671380141; bh=jAGMBJQ8iKFm4a6UjusnlvElGzGbYmjlZEsQBr9PFdQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BDnwl28mSxzvOLUUYnhULqBVbOldF/k5ly2v2QwyJMgBIEVR+Q3daaE6xl9XrrqwZ EhDjZkM+Irs/QjcTjmBAq1Jj3xL7pNeqqvSzSZrYJA4j1G1j/nwEzwhMP0mxs4fXE3 41T5i690AnXoQlaCoV+z4bIY0oWvCUZcLtK46Msoj7/kQLljaFZqUsF+0y7Y3j4kgP 1SgPkXE/en/YuNXrNQeRpUZ81Kf3e+Bn+kX53w0yHo70sPzmK2HmiZLqDYXCTfBzKU jZsM0MHIIpp3sla1XGiL0gKWnnzwo7hvs0MBVA2QzF+dl9ONmjNuKUb1DTOO8tQ1zR 3kQn0BP9/QioA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrii Nakryiko , Daniel Borkmann , Sasha Levin , ast@kernel.org, bpf@vger.kernel.org Subject: [PATCH AUTOSEL 5.15 39/46] libbpf: Avoid enum forward-declarations in public API in C++ mode Date: Sun, 18 Dec 2022 11:12:37 -0500 Message-Id: <20221218161244.930785-39-sashal@kernel.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20221218161244.930785-1-sashal@kernel.org> References: <20221218161244.930785-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Andrii Nakryiko [ Upstream commit b42693415b86f608049cf1b4870adc1dc65e58b0 ] C++ enum forward declarations are fundamentally not compatible with pure C enum definitions, and so libbpf's use of `enum bpf_stats_type;` forward declaration in libbpf/bpf.h public API header is causing C++ compilation issues. More details can be found in [0], but it comes down to C++ supporting enum forward declaration only with explicitly specified backing type: enum bpf_stats_type: int; In C (and I believe it's a GCC extension also), such forward declaration is simply: enum bpf_stats_type; Further, in Linux UAPI this enum is defined in pure C way: enum bpf_stats_type { BPF_STATS_RUN_TIME = 0; } And even though in both cases backing type is int, which can be confirmed by looking at DWARF information, for C++ compiler actual enum definition and forward declaration are incompatible. To eliminate this problem, for C++ mode define input argument as int, which makes enum unnecessary in libbpf public header. This solves the issue and as demonstrated by next patch doesn't cause any unwanted compiler warnings, at least with default warnings setting. [0] https://stackoverflow.com/questions/42766839/c11-enum-forward-causes-underlying-type-mismatch [1] Closes: https://github.com/libbpf/libbpf/issues/249 Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20221130200013.2997831-1-andrii@kernel.org Signed-off-by: Sasha Levin --- tools/lib/bpf/bpf.h | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h index 6fffb3cdf39b..49bd43b998c8 100644 --- a/tools/lib/bpf/bpf.h +++ b/tools/lib/bpf/bpf.h @@ -249,8 +249,15 @@ LIBBPF_API int bpf_task_fd_query(int pid, int fd, __u32 flags, char *buf, __u32 *buf_len, __u32 *prog_id, __u32 *fd_type, __u64 *probe_offset, __u64 *probe_addr); +#ifdef __cplusplus +/* forward-declaring enums in C++ isn't compatible with pure C enums, so + * instead define bpf_enable_stats() as accepting int as an input + */ +LIBBPF_API int bpf_enable_stats(int type); +#else enum bpf_stats_type; /* defined in up-to-date linux/bpf.h */ LIBBPF_API int bpf_enable_stats(enum bpf_stats_type type); +#endif struct bpf_prog_bind_opts { size_t sz; /* size of this struct for forward/backward compatibility */ -- 2.35.1