On Sat, Jun 3, 2023 at 2:17 AM Alexei Starovoitov alexei.starovoitov@gmail.com wrote:
On Fri, Jun 2, 2023 at 12:01 AM menglong8.dong@gmail.com wrote:
From: Menglong Dong imagedong@tencent.com
According to the current kernel version, below is a statistics of the function arguments count:
argument count | FUNC_PROTO count 7 | 367 8 | 196 9 | 71 10 | 43 11 | 22 12 | 10 13 | 15 14 | 4 15 | 0 16 | 1
It's hard to statisics the function count, so I use FUNC_PROTO in the btf of vmlinux instead. The function with 16 arguments is ZSTD_buildCTable(), which I think can be ignored.
Therefore, let's make the maximum of function arguments count 14. It used to be 12, but it seems that there is no harm to make it big enough.
I think we're just fine at 12. People need to fix their code. ZSTD_buildCTable should be first in line. Passing arguments on the stack is not efficient from performance pov.
But we still need to keep this part:
@@ -2273,7 +2273,8 @@ bool btf_ctx_access(int off, int size, enum bpf_access_type type, static inline bool bpf_tracing_ctx_access(int off, int size, enum bpf_access_type type) { - if (off < 0 || off >= sizeof(__u64) * MAX_BPF_FUNC_ARGS) + /* "+1" here is for FEXIT return value. */ + if (off < 0 || off >= sizeof(__u64) * (MAX_BPF_FUNC_ARGS + 1)) return false; if (type != BPF_READ) return false;
Isn't it? Otherwise, it will make that the maximum arguments is 12 for FENTRY, but 11 for FEXIT, as FEXIT needs to store the return value in ctx.
How about that we change bpf_tracing_ctx_access() into:
static inline bool bpf_tracing_ctx_access(int off, int size, enum bpf_access_type type, int max_args)
And the caller can pass MAX_BPF_FUNC_ARGS to it on no-FEXIT, and 'MAX_BPF_FUNC_ARGS + 1' on FEXIT.
What do you think?
Thanks! Menglong Dong