diff mbox series

[bpf] bpf: syscall_nrs: fix no previous prototype for "syscall_defines"

Message ID 20240919195454.73358-1-kerneljasonxing@gmail.com (mailing list archive)
State Changes Requested
Delegated to: BPF
Headers show
Series [bpf] bpf: syscall_nrs: fix no previous prototype for "syscall_defines" | expand

Checks

Context Check Description
bpf/vmtest-bpf-VM_Test-0 success Logs for Lint
bpf/vmtest-bpf-VM_Test-1 success Logs for ShellCheck
bpf/vmtest-bpf-VM_Test-2 success Logs for Unittests
bpf/vmtest-bpf-VM_Test-3 success Logs for Validate matrix.py
bpf/vmtest-bpf-VM_Test-5 success Logs for aarch64-gcc / build-release
bpf/vmtest-bpf-VM_Test-4 success Logs for aarch64-gcc / build / build for aarch64 with gcc
bpf/vmtest-bpf-VM_Test-12 success Logs for s390x-gcc / build-release
bpf/vmtest-bpf-VM_Test-10 success Logs for aarch64-gcc / veristat
netdev/series_format success Single patches do not need cover letters
netdev/tree_selection success Clearly marked for bpf
netdev/ynl success Generated files up to date; no warnings/errors; no diff in generated;
netdev/fixes_present fail Series targets non-next tree, but doesn't contain any Fixes tags
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 7 this patch: 7
netdev/build_tools success No tools touched, skip
netdev/cc_maintainers success CCed 13 of 13 maintainers
netdev/build_clang success Errors and warnings before: 7 this patch: 7
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 7 this patch: 7
netdev/checkpatch warning WARNING: externs should be avoided in .c files
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0
bpf/vmtest-bpf-VM_Test-6 success Logs for aarch64-gcc / test (test_maps, false, 360) / test_maps on aarch64 with gcc
bpf/vmtest-bpf-VM_Test-9 success Logs for aarch64-gcc / test (test_verifier, false, 360) / test_verifier on aarch64 with gcc
bpf/vmtest-bpf-VM_Test-16 success Logs for s390x-gcc / veristat
bpf/vmtest-bpf-VM_Test-21 success Logs for x86_64-gcc / test (test_progs, false, 360) / test_progs on x86_64 with gcc
bpf/vmtest-bpf-VM_Test-11 success Logs for s390x-gcc / build / build for s390x with gcc
bpf/vmtest-bpf-VM_Test-20 success Logs for x86_64-gcc / test (test_maps, false, 360) / test_maps on x86_64 with gcc
bpf/vmtest-bpf-VM_Test-26 fail Logs for x86_64-gcc / veristat / veristat on x86_64 with gcc
bpf/vmtest-bpf-VM_Test-19 success Logs for x86_64-gcc / build-release
bpf/vmtest-bpf-VM_Test-17 success Logs for set-matrix
bpf/vmtest-bpf-VM_Test-22 success Logs for x86_64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with gcc
bpf/vmtest-bpf-VM_Test-18 success Logs for x86_64-gcc / build / build for x86_64 with gcc
bpf/vmtest-bpf-VM_Test-28 success Logs for x86_64-llvm-17 / build-release / build for x86_64 with llvm-17-O2
bpf/vmtest-bpf-VM_Test-29 success Logs for x86_64-llvm-17 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-17
bpf/vmtest-bpf-VM_Test-25 success Logs for x86_64-gcc / test (test_verifier, false, 360) / test_verifier on x86_64 with gcc
bpf/vmtest-bpf-VM_Test-23 success Logs for x86_64-gcc / test (test_progs_no_alu32_parallel, true, 30) / test_progs_no_alu32_parallel on x86_64 with gcc
bpf/vmtest-bpf-VM_Test-30 success Logs for x86_64-llvm-17 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-17
bpf/vmtest-bpf-VM_Test-27 success Logs for x86_64-llvm-17 / build / build for x86_64 with llvm-17
bpf/vmtest-bpf-VM_Test-24 success Logs for x86_64-gcc / test (test_progs_parallel, true, 30) / test_progs_parallel on x86_64 with gcc
bpf/vmtest-bpf-VM_Test-32 success Logs for x86_64-llvm-17 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-17
bpf/vmtest-bpf-VM_Test-37 success Logs for x86_64-llvm-18 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-18
bpf/vmtest-bpf-VM_Test-31 success Logs for x86_64-llvm-17 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-17
bpf/vmtest-bpf-VM_Test-35 success Logs for x86_64-llvm-18 / build-release / build for x86_64 with llvm-18-O2
bpf/vmtest-bpf-VM_Test-39 success Logs for x86_64-llvm-18 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-18
bpf/vmtest-bpf-VM_Test-38 success Logs for x86_64-llvm-18 / test (test_progs_cpuv4, false, 360) / test_progs_cpuv4 on x86_64 with llvm-18
bpf/vmtest-bpf-VM_Test-34 success Logs for x86_64-llvm-18 / build / build for x86_64 with llvm-18
bpf/vmtest-bpf-VM_Test-40 success Logs for x86_64-llvm-18 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-18
bpf/vmtest-bpf-VM_Test-41 success Logs for x86_64-llvm-18 / veristat
bpf/vmtest-bpf-VM_Test-36 success Logs for x86_64-llvm-18 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-18
bpf/vmtest-bpf-VM_Test-33 success Logs for x86_64-llvm-17 / veristat
bpf/vmtest-bpf-VM_Test-7 success Logs for aarch64-gcc / test (test_progs, false, 360) / test_progs on aarch64 with gcc
bpf/vmtest-bpf-VM_Test-15 success Logs for s390x-gcc / test (test_verifier, false, 360) / test_verifier on s390x with gcc
bpf/vmtest-bpf-VM_Test-14 success Logs for s390x-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on s390x with gcc
bpf/vmtest-bpf-VM_Test-8 success Logs for aarch64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on aarch64 with gcc
bpf/vmtest-bpf-PR fail PR summary
bpf/vmtest-bpf-VM_Test-13 success Logs for s390x-gcc / test (test_progs, false, 360) / test_progs on s390x with gcc

Commit Message

Jason Xing Sept. 19, 2024, 7:54 p.m. UTC 
From: Jason Xing <kernelxing@tencent.com>

In some environments (gcc treated as error in W=1, which is default), if we
make -C samples/bpf/, it will be stopped because of
"no previous prototype" error like this:

  ../samples/bpf/syscall_nrs.c:7:6:
  error: no previous prototype for ‘syscall_defines’ [-Werror=missing-prototypes]
   void syscall_defines(void)
        ^~~~~~~~~~~~~~~

Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
I'm not sure which tree I should target, sorry about that.
---
 samples/bpf/syscall_nrs.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

Alexei Starovoitov Sept. 19, 2024, 9:17 p.m. UTC | #1 
On Thu, Sep 19, 2024 at 9:55 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
>
> From: Jason Xing <kernelxing@tencent.com>
>
> In some environments (gcc treated as error in W=1, which is default), if we
> make -C samples/bpf/, it will be stopped because of
> "no previous prototype" error like this:
>
>   ../samples/bpf/syscall_nrs.c:7:6:
>   error: no previous prototype for ‘syscall_defines’ [-Werror=missing-prototypes]
>    void syscall_defines(void)
>         ^~~~~~~~~~~~~~~

samples/bpf/ doesn't accept patches any more.
If this samples/test is useful, refactor it to the test_progs framework.
Otherwise delete it.

pw-bot: cr
Jason Xing Sept. 19, 2024, 9:23 p.m. UTC | #2 
On Thu, Sep 19, 2024 at 11:17 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Thu, Sep 19, 2024 at 9:55 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
> >
> > From: Jason Xing <kernelxing@tencent.com>
> >
> > In some environments (gcc treated as error in W=1, which is default), if we
> > make -C samples/bpf/, it will be stopped because of
> > "no previous prototype" error like this:
> >
> >   ../samples/bpf/syscall_nrs.c:7:6:
> >   error: no previous prototype for ‘syscall_defines’ [-Werror=missing-prototypes]
> >    void syscall_defines(void)
> >         ^~~~~~~~~~~~~~~
>
> samples/bpf/ doesn't accept patches any more.

Thanks for your reminder. I didn't know that.

> If this samples/test is useful, refactor it to the test_progs framework.
> Otherwise delete it.

I'm trying to use the samples/test to do some tests to verify if some
functions like bpf_sock_ops_cb_flags_set() can work. Then I
encountered the issue as this patch said.
Jason Xing Sept. 20, 2024, 7:36 p.m. UTC | #3 
On Thu, Sep 19, 2024 at 11:17 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Thu, Sep 19, 2024 at 9:55 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
> >
> > From: Jason Xing <kernelxing@tencent.com>
> >
> > In some environments (gcc treated as error in W=1, which is default), if we
> > make -C samples/bpf/, it will be stopped because of
> > "no previous prototype" error like this:
> >
> >   ../samples/bpf/syscall_nrs.c:7:6:
> >   error: no previous prototype for ‘syscall_defines’ [-Werror=missing-prototypes]
> >    void syscall_defines(void)
> >         ^~~~~~~~~~~~~~~
>
> samples/bpf/ doesn't accept patches any more.
> If this samples/test is useful, refactor it to the test_progs framework.
> Otherwise delete it.
>
> pw-bot: cr

After reconsidering what Alexei said, I still feel we could take this
patch? It is because:
1) the patch itself  is more of a fix instead of optimization,
2)as long as samples/bpf exists in the kernel, we cannot easily let
it(issues) go and ignore it.

Applying such a patch won't cause any further confusion, right? As we
can see, it's like a fix which does not introduce anything new here.

What do you bpf maintainers think?

Thanks,
Jason
Andrii Nakryiko Sept. 27, 2024, 11:08 p.m. UTC | #4 
On Fri, Sep 20, 2024 at 12:37 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
>
> On Thu, Sep 19, 2024 at 11:17 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Thu, Sep 19, 2024 at 9:55 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
> > >
> > > From: Jason Xing <kernelxing@tencent.com>
> > >
> > > In some environments (gcc treated as error in W=1, which is default), if we
> > > make -C samples/bpf/, it will be stopped because of
> > > "no previous prototype" error like this:
> > >
> > >   ../samples/bpf/syscall_nrs.c:7:6:
> > >   error: no previous prototype for ‘syscall_defines’ [-Werror=missing-prototypes]
> > >    void syscall_defines(void)
> > >         ^~~~~~~~~~~~~~~
> >
> > samples/bpf/ doesn't accept patches any more.
> > If this samples/test is useful, refactor it to the test_progs framework.
> > Otherwise delete it.
> >
> > pw-bot: cr
>
> After reconsidering what Alexei said, I still feel we could take this
> patch? It is because:
> 1) the patch itself  is more of a fix instead of optimization,
> 2)as long as samples/bpf exists in the kernel, we cannot easily let
> it(issues) go and ignore it.
>
> Applying such a patch won't cause any further confusion, right? As we
> can see, it's like a fix which does not introduce anything new here.
>
> What do you bpf maintainers think?

I think it's fine to minimally fix the issue in samples/bpf, but I
don't think this weirdly-looking extra declaration is the best fix.

Can you mark that function static? Will that work? Or, as a plan B,
use pragma to disable this warning, it's clearly "expected" in this
case.

>
> Thanks,
> Jason
Jason Xing Sept. 28, 2024, 5:22 a.m. UTC | #5 
Hello Andrii,

On Sat, Sep 28, 2024 at 7:08 AM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Fri, Sep 20, 2024 at 12:37 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
> >
> > On Thu, Sep 19, 2024 at 11:17 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > On Thu, Sep 19, 2024 at 9:55 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
> > > >
> > > > From: Jason Xing <kernelxing@tencent.com>
> > > >
> > > > In some environments (gcc treated as error in W=1, which is default), if we
> > > > make -C samples/bpf/, it will be stopped because of
> > > > "no previous prototype" error like this:
> > > >
> > > >   ../samples/bpf/syscall_nrs.c:7:6:
> > > >   error: no previous prototype for ‘syscall_defines’ [-Werror=missing-prototypes]
> > > >    void syscall_defines(void)
> > > >         ^~~~~~~~~~~~~~~
> > >
> > > samples/bpf/ doesn't accept patches any more.
> > > If this samples/test is useful, refactor it to the test_progs framework.
> > > Otherwise delete it.
> > >
> > > pw-bot: cr
> >
> > After reconsidering what Alexei said, I still feel we could take this
> > patch? It is because:
> > 1) the patch itself  is more of a fix instead of optimization,
> > 2)as long as samples/bpf exists in the kernel, we cannot easily let
> > it(issues) go and ignore it.
> >
> > Applying such a patch won't cause any further confusion, right? As we
> > can see, it's like a fix which does not introduce anything new here.
> >
> > What do you bpf maintainers think?
>
> I think it's fine to minimally fix the issue in samples/bpf, but I
> don't think this weirdly-looking extra declaration is the best fix.

Thanks for your reply.

>
> Can you mark that function static? Will that work?

Not really, it will print:
samples/bpf/syscall_nrs.c:7:13: error: ‘syscall_defines’ defined but
not used [-Werror=unused-function]
 static void syscall_defines(void)
             ^~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

> Or, as a plan B,
> use pragma to disable this warning, it's clearly "expected" in this
> case.

Yes, I admit the use in this function is "expected" like you said
because this file will be converted into a .h file. Could you kindly
show me more hints on how to disable the warning when compiling? I
tried to remove something like "-Wmissing-prototypes", but the warning
still happens.

Thanks,
Jason
Andrii Nakryiko Sept. 30, 2024, 10:06 p.m. UTC | #6 
On Fri, Sep 27, 2024 at 10:22 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
>
> Hello Andrii,
>
> On Sat, Sep 28, 2024 at 7:08 AM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > On Fri, Sep 20, 2024 at 12:37 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
> > >
> > > On Thu, Sep 19, 2024 at 11:17 PM Alexei Starovoitov
> > > <alexei.starovoitov@gmail.com> wrote:
> > > >
> > > > On Thu, Sep 19, 2024 at 9:55 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
> > > > >
> > > > > From: Jason Xing <kernelxing@tencent.com>
> > > > >
> > > > > In some environments (gcc treated as error in W=1, which is default), if we
> > > > > make -C samples/bpf/, it will be stopped because of
> > > > > "no previous prototype" error like this:
> > > > >
> > > > >   ../samples/bpf/syscall_nrs.c:7:6:
> > > > >   error: no previous prototype for ‘syscall_defines’ [-Werror=missing-prototypes]
> > > > >    void syscall_defines(void)
> > > > >         ^~~~~~~~~~~~~~~
> > > >
> > > > samples/bpf/ doesn't accept patches any more.
> > > > If this samples/test is useful, refactor it to the test_progs framework.
> > > > Otherwise delete it.
> > > >
> > > > pw-bot: cr
> > >
> > > After reconsidering what Alexei said, I still feel we could take this
> > > patch? It is because:
> > > 1) the patch itself  is more of a fix instead of optimization,
> > > 2)as long as samples/bpf exists in the kernel, we cannot easily let
> > > it(issues) go and ignore it.
> > >
> > > Applying such a patch won't cause any further confusion, right? As we
> > > can see, it's like a fix which does not introduce anything new here.
> > >
> > > What do you bpf maintainers think?
> >
> > I think it's fine to minimally fix the issue in samples/bpf, but I
> > don't think this weirdly-looking extra declaration is the best fix.
>
> Thanks for your reply.
>
> >
> > Can you mark that function static? Will that work?
>
> Not really, it will print:
> samples/bpf/syscall_nrs.c:7:13: error: ‘syscall_defines’ defined but
> not used [-Werror=unused-function]
>  static void syscall_defines(void)
>              ^~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
> > Or, as a plan B,
> > use pragma to disable this warning, it's clearly "expected" in this
> > case.
>
> Yes, I admit the use in this function is "expected" like you said
> because this file will be converted into a .h file. Could you kindly
> show me more hints on how to disable the warning when compiling? I
> tried to remove something like "-Wmissing-prototypes", but the warning
> still happens.
>

Grep for "#pragma GCC diagnostic ignored" uses in kernel sources.

> Thanks,
> Jason
Jason Xing Oct. 1, 2024, 12:51 a.m. UTC | #7 
On Tue, Oct 1, 2024 at 6:06 AM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Fri, Sep 27, 2024 at 10:22 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
> >
> > Hello Andrii,
> >
> > On Sat, Sep 28, 2024 at 7:08 AM Andrii Nakryiko
> > <andrii.nakryiko@gmail.com> wrote:
> > >
> > > On Fri, Sep 20, 2024 at 12:37 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
> > > >
> > > > On Thu, Sep 19, 2024 at 11:17 PM Alexei Starovoitov
> > > > <alexei.starovoitov@gmail.com> wrote:
> > > > >
> > > > > On Thu, Sep 19, 2024 at 9:55 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
> > > > > >
> > > > > > From: Jason Xing <kernelxing@tencent.com>
> > > > > >
> > > > > > In some environments (gcc treated as error in W=1, which is default), if we
> > > > > > make -C samples/bpf/, it will be stopped because of
> > > > > > "no previous prototype" error like this:
> > > > > >
> > > > > >   ../samples/bpf/syscall_nrs.c:7:6:
> > > > > >   error: no previous prototype for ‘syscall_defines’ [-Werror=missing-prototypes]
> > > > > >    void syscall_defines(void)
> > > > > >         ^~~~~~~~~~~~~~~
> > > > >
> > > > > samples/bpf/ doesn't accept patches any more.
> > > > > If this samples/test is useful, refactor it to the test_progs framework.
> > > > > Otherwise delete it.
> > > > >
> > > > > pw-bot: cr
> > > >
> > > > After reconsidering what Alexei said, I still feel we could take this
> > > > patch? It is because:
> > > > 1) the patch itself  is more of a fix instead of optimization,
> > > > 2)as long as samples/bpf exists in the kernel, we cannot easily let
> > > > it(issues) go and ignore it.
> > > >
> > > > Applying such a patch won't cause any further confusion, right? As we
> > > > can see, it's like a fix which does not introduce anything new here.
> > > >
> > > > What do you bpf maintainers think?
> > >
> > > I think it's fine to minimally fix the issue in samples/bpf, but I
> > > don't think this weirdly-looking extra declaration is the best fix.
> >
> > Thanks for your reply.
> >
> > >
> > > Can you mark that function static? Will that work?
> >
> > Not really, it will print:
> > samples/bpf/syscall_nrs.c:7:13: error: ‘syscall_defines’ defined but
> > not used [-Werror=unused-function]
> >  static void syscall_defines(void)
> >              ^~~~~~~~~~~~~~~
> > cc1: all warnings being treated as errors
> >
> > > Or, as a plan B,
> > > use pragma to disable this warning, it's clearly "expected" in this
> > > case.
> >
> > Yes, I admit the use in this function is "expected" like you said
> > because this file will be converted into a .h file. Could you kindly
> > show me more hints on how to disable the warning when compiling? I
> > tried to remove something like "-Wmissing-prototypes", but the warning
> > still happens.
> >
>
> Grep for "#pragma GCC diagnostic ignored" uses in kernel sources.

Thanks a lot! It works. Let me re-post it to "fix" this issue.

Thanks,
Jason
diff mbox series

Patch

diff --git a/samples/bpf/syscall_nrs.c b/samples/bpf/syscall_nrs.c
index 88f940052450..5f40a29034b6 100644
--- a/samples/bpf/syscall_nrs.c
+++ b/samples/bpf/syscall_nrs.c
@@ -4,6 +4,8 @@ 
 
 #define SYSNR(_NR) DEFINE(SYS ## _NR, _NR)
 
+void syscall_defines(void);
+
 void syscall_defines(void)
 {
 	COMMENT("Linux system call numbers.");