public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Yafang Shao" <laoar.shao@gmail.com>
Cc: "kernel test robot" <lkp@intel.com>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Alexei Starovoitov" <ast@kernel.org>,
	bpf@vger.kernel.org, cgroups@vger.kernel.org,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	"Hao Luo" <haoluo@google.com>,
	"John Fastabend" <john.fastabend@gmail.com>,
	"Jiri Olsa" <jolsa@kernel.org>, "KP Singh" <kpsingh@kernel.org>,
	lizefan.x@bytedance.com, "Waiman Long" <longman@redhat.com>,
	"Martin KaFai Lau" <martin.lau@linux.dev>,
	mkoutny@suse.com, oe-kbuild-all@lists.linux.dev,
	"kernel test robot" <oliver.sang@intel.com>,
	"Stanislav Fomichev" <sdf@google.com>,
	sinquersw@gmail.com, "Song Liu" <song@kernel.org>,
	"Tejun Heo" <tj@kernel.org>,
	"Yonghong Song" <yonghong.song@linux.dev>,
	yosryahmed@google.com,
	"Kumar Kartikeya Dwivedi" <memxor@gmail.com>
Subject: Re: [PATCH bpf-next] compiler-gcc: Ignore -Wmissing-prototypes warning for older GCC
Date: Sun, 05 Nov 2023 14:01:04 +0100	[thread overview]
Message-ID: <d178b5b5-4171-4e76-a486-c20d5f081448@app.fastmail.com> (raw)
In-Reply-To: <CALOAHbCt4-kDGoW=4R0EarPNV2yNcwy3exkVrn6Tz5Ng8M8gvg@mail.gmail.com>

On Sun, Nov 5, 2023, at 12:54, Yafang Shao wrote:
> On Sun, Nov 5, 2023 at 4:24 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Sun, Nov 5, 2023, at 07:22, Yafang Shao wrote:
>> > To address this, we should also suppress the "-Wmissing-prototypes" warning
>> > for older GCC versions. Since "#pragma GCC diagnostic push" is supported as
>> > of GCC 4.6, it is acceptable to ignore these warnings for GCC >= 5.1.0.
>>
>> Not sure why these need to be suppressed like this at all,
>> can't you just add the prototype somewhere?
>
> BPF kfuncs are intended for use within BPF programs, and they should
> not be called from other parts of the kernel. Consequently, it is not
> appropriate to include their prototypes in a kernel header file.

How does the caller in the BPF program get the prototype?

>> > @@ -131,14 +131,14 @@
>> >  #define __diag_str(s)                __diag_str1(s)
>> >  #define __diag(s)            _Pragma(__diag_str(GCC diagnostic s))
>> >
>> > -#if GCC_VERSION >= 80000
>> > -#define __diag_GCC_8(s)              __diag(s)
>> > +#if GCC_VERSION >= 50100
>> > +#define __diag_GCC_5(s)              __diag(s)
>> >  #else
>> > -#define __diag_GCC_8(s)
>> > +#define __diag_GCC_5(s)
>> >  #endif
>> >
>>
>> This breaks all uses of __diag_ignore that specify
>> version 8 directly. Just add the macros for each version
>> from 5 to 14 here.
>
> It seems that __diag_GCC_8() or __diag_GCC() are not directly used
> anywhere in the kernel, right?

I see three instances:

drivers/net/ethernet/renesas/sh_eth.c:__diag_ignore(GCC, 8, "-Woverride-init",
include/linux/compat.h:     __diag_ignore(GCC, 8, "-Wattribute-alias",                              include/linux/syscalls.h:   __diag_ignore(GCC, 8, "-Wattribute-alias",                      

The override-init one should probably use version 5 as well,
but I think the -Wattribute-alias ones require GCC 8 and otherwise
cause a warning about an unknown warning option.

__diag_ignore_all() would also be wrong for the override-init
because the option has a different name in clang
(-Winitializer-overrides).

> Therefore it won't break anything if we just replace __diag_GCC_8()
> with __diag_GCC_5().
> It may be cumbersome to add the macrocs for every GCC version if they
> aren't actively used.

For the _all variant, I would prefer to completely remove
the version logic and just use __diag() directly. I think the
entire point of this is that it is used on all supported
versions.

      Arnd

  reply	other threads:[~2023-11-05 13:01 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-29  6:14 [PATCH v3 bpf-next 00/11] bpf, cgroup: Add BPF support for cgroup1 hierarchy Yafang Shao
2023-10-29  6:14 ` [PATCH v3 bpf-next 01/11] cgroup: Remove unnecessary list_empty() Yafang Shao
2023-11-09 21:09   ` Tejun Heo
2023-10-29  6:14 ` [PATCH v3 bpf-next 02/11] cgroup: Make operations on the cgroup root_list RCU safe Yafang Shao
2023-11-09 21:19   ` Tejun Heo
2023-10-29  6:14 ` [PATCH v3 bpf-next 03/11] cgroup: Eliminate the need for cgroup_mutex in proc_cgroup_show() Yafang Shao
2023-11-09 21:20   ` Tejun Heo
2023-10-29  6:14 ` [PATCH v3 bpf-next 04/11] cgroup: Add annotation for holding namespace_sem in current_cgns_cgroup_from_root() Yafang Shao
2023-11-09 21:22   ` Tejun Heo
2023-10-29  6:14 ` [PATCH v3 bpf-next 05/11] cgroup: Add a new helper for cgroup1 hierarchy Yafang Shao
2023-11-09  9:33   ` Hou Tao
2023-11-09 21:27   ` Tejun Heo
2023-11-09 23:30   ` Tejun Heo
2023-11-10  2:37     ` Yafang Shao
2023-10-29  6:14 ` [PATCH v3 bpf-next 06/11] bpf: Add a new kfunc " Yafang Shao
2023-10-30  9:00   ` kernel test robot
2023-10-30 11:35     ` Yafang Shao
2023-10-30 13:59       ` Jiri Olsa
2023-10-31  2:40         ` Yafang Shao
2023-10-31  4:22           ` David Marchevsky
2023-11-03  8:18   ` kernel test robot
2023-11-03  8:49     ` Yafang Shao
2023-11-05  6:22     ` [PATCH bpf-next] compiler-gcc: Ignore -Wmissing-prototypes warning for older GCC Yafang Shao
2023-11-05  8:24       ` Arnd Bergmann
2023-11-05 11:54         ` Yafang Shao
2023-11-05 13:01           ` Arnd Bergmann [this message]
2023-11-05 13:50             ` Yafang Shao
2023-11-06  3:18     ` [PATCH v2 bpf-next] compiler-gcc: Suppress -Wmissing-prototypes warning for all supported GCC Yafang Shao
2023-11-09 18:23       ` Alexei Starovoitov
2023-11-10  6:34         ` Arnd Bergmann
2023-11-10  7:48           ` Yafang Shao
2023-11-10 16:00       ` patchwork-bot+netdevbpf
2023-11-09 21:29   ` [PATCH v3 bpf-next 06/11] bpf: Add a new kfunc for cgroup1 hierarchy Tejun Heo
2023-10-29  6:14 ` [PATCH v3 bpf-next 07/11] selftests/bpf: Fix issues in setup_classid_environment() Yafang Shao
2023-10-29  6:14 ` [PATCH v3 bpf-next 08/11] selftests/bpf: Add parallel support for classid Yafang Shao
2023-10-29  6:14 ` [PATCH v3 bpf-next 09/11] selftests/bpf: Add a new cgroup helper get_classid_cgroup_id() Yafang Shao
2023-10-29  6:14 ` [PATCH v3 bpf-next 10/11] selftests/bpf: Add a new cgroup helper get_cgroup_hierarchy_id() Yafang Shao
2023-11-09 21:32   ` Tejun Heo
2023-11-10  2:40     ` Yafang Shao
2023-10-29  6:14 ` [PATCH v3 bpf-next 11/11] selftests/bpf: Add selftests for cgroup1 hierarchy Yafang Shao
2023-11-09 21:36 ` [PATCH v3 bpf-next 00/11] bpf, cgroup: Add BPF support " Tejun Heo
2023-11-09 23:06   ` Alexei Starovoitov
2023-11-09 23:28 ` Tejun Heo
2023-11-09 23:35   ` Alexei Starovoitov
2023-11-10  6:04     ` Yafang Shao
2023-11-10 17:05       ` Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d178b5b5-4171-4e76-a486-c20d5f081448@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=hannes@cmpxchg.org \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=laoar.shao@gmail.com \
    --cc=lizefan.x@bytedance.com \
    --cc=lkp@intel.com \
    --cc=longman@redhat.com \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=mkoutny@suse.com \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=oliver.sang@intel.com \
    --cc=sdf@google.com \
    --cc=sinquersw@gmail.com \
    --cc=song@kernel.org \
    --cc=tj@kernel.org \
    --cc=yonghong.song@linux.dev \
    --cc=yosryahmed@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox