[PATCH] perf trace: Increase syscall handler map size to 1024

[PATCH] perf trace: Increase syscall handler map size to 1024

[Namhyung Kim]

The syscalls_sys_{enter,exit} map in augmented_raw_syscalls.bpf.c has
max entries of 512.  Usually syscall numbers are smaller than this but
x86 has x32 ABI where syscalls start from 512.

That makes trace__init_syscalls_bpf_prog_array_maps() fail in the middle
of the loop when it accesses those keys.  As the loop iteration is not
ordered by syscall numbers anymore, the failure can affect non-x32
syscalls.

Let's increase the map size to 1024 so that it can handle those ABIs
too.  While most systems won't need this, increasing the size will be
safer for potential future changes.

Cc: Howard Chu <howardchu95@gmail.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
 tools/perf/util/bpf_skel/augmented_raw_syscalls.bpf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/bpf_skel/augmented_raw_syscalls.bpf.c b/tools/perf/util/bpf_skel/augmented_raw_syscalls.bpf.c
index e4352881e3faa602..c814ab01f9c7800f 100644
--- a/tools/perf/util/bpf_skel/augmented_raw_syscalls.bpf.c
+++ b/tools/perf/util/bpf_skel/augmented_raw_syscalls.bpf.c
@@ -44,7 +44,7 @@ struct syscalls_sys_enter {
 	__uint(type, BPF_MAP_TYPE_PROG_ARRAY);
 	__type(key, __u32);
 	__type(value, __u32);
-	__uint(max_entries, 512);
+	__uint(max_entries, 1024);
 } syscalls_sys_enter SEC(".maps");
 
 /*
@@ -56,7 +56,7 @@ struct syscalls_sys_exit {
 	__uint(type, BPF_MAP_TYPE_PROG_ARRAY);
 	__type(key, __u32);
 	__type(value, __u32);
-	__uint(max_entries, 512);
+	__uint(max_entries, 1024);
 } syscalls_sys_exit SEC(".maps");
 
 struct syscall_enter_args {
-- 
2.49.0.1101.gccaa498523-goog

Re: [PATCH] perf trace: Increase syscall handler map size to 1024

[Howard Chu]

Hello Namhyung,

On Mon, May 19, 2025 at 4:25 PM Namhyung Kim <namhyung@kernel.org> wrote:
>
> The syscalls_sys_{enter,exit} map in augmented_raw_syscalls.bpf.c has
> max entries of 512.  Usually syscall numbers are smaller than this but
> x86 has x32 ABI where syscalls start from 512.
>
> That makes trace__init_syscalls_bpf_prog_array_maps() fail in the middle
> of the loop when it accesses those keys.  As the loop iteration is not
> ordered by syscall numbers anymore, the failure can affect non-x32
> syscalls.
>
> Let's increase the map size to 1024 so that it can handle those ABIs
> too.  While most systems won't need this, increasing the size will be
> safer for potential future changes.
>
> Cc: Howard Chu <howardchu95@gmail.com>
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>

Reviewed-by: Howard Chu <howardchu95@gmail.com>

Thanks,
Howard

Re: [PATCH] perf trace: Increase syscall handler map size to 1024

[Ian Rogers]

On Mon, May 19, 2025 at 4:36 PM Howard Chu <howardchu95@gmail.com> wrote:
>
> Hello Namhyung,
>
> On Mon, May 19, 2025 at 4:25 PM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > The syscalls_sys_{enter,exit} map in augmented_raw_syscalls.bpf.c has
> > max entries of 512.  Usually syscall numbers are smaller than this but
> > x86 has x32 ABI where syscalls start from 512.
> >
> > That makes trace__init_syscalls_bpf_prog_array_maps() fail in the middle
> > of the loop when it accesses those keys.  As the loop iteration is not
> > ordered by syscall numbers anymore, the failure can affect non-x32
> > syscalls.
> >
> > Let's increase the map size to 1024 so that it can handle those ABIs
> > too.  While most systems won't need this, increasing the size will be
> > safer for potential future changes.

Do we need to worry about MIPS where syscalls can be offset by 1000s?
https://lore.kernel.org/lkml/8ed7dfb2-1e4d-4aa4-a04b-0397a89365d1@app.fastmail.com/
We could do with a map that combines BPF_MAP_TYPE_HASH with the tails
calls of BPF_MAP_TYPE_PROG_ARRAY.

Thanks,
Ian

> > Cc: Howard Chu <howardchu95@gmail.com>
> > Signed-off-by: Namhyung Kim <namhyung@kernel.org>
>
> Reviewed-by: Howard Chu <howardchu95@gmail.com>
>
> Thanks,
> Howard

Re: [PATCH] perf trace: Increase syscall handler map size to 1024

[Namhyung Kim]

Hi Ian,

On Tue, May 20, 2025 at 08:05:37AM -0700, Ian Rogers wrote:
> On Mon, May 19, 2025 at 4:36 PM Howard Chu <howardchu95@gmail.com> wrote:
> >
> > Hello Namhyung,
> >
> > On Mon, May 19, 2025 at 4:25 PM Namhyung Kim <namhyung@kernel.org> wrote:
> > >
> > > The syscalls_sys_{enter,exit} map in augmented_raw_syscalls.bpf.c has
> > > max entries of 512.  Usually syscall numbers are smaller than this but
> > > x86 has x32 ABI where syscalls start from 512.
> > >
> > > That makes trace__init_syscalls_bpf_prog_array_maps() fail in the middle
> > > of the loop when it accesses those keys.  As the loop iteration is not
> > > ordered by syscall numbers anymore, the failure can affect non-x32
> > > syscalls.
> > >
> > > Let's increase the map size to 1024 so that it can handle those ABIs
> > > too.  While most systems won't need this, increasing the size will be
> > > safer for potential future changes.
> 
> Do we need to worry about MIPS where syscalls can be offset by 1000s?
> https://lore.kernel.org/lkml/8ed7dfb2-1e4d-4aa4-a04b-0397a89365d1@app.fastmail.com/

Argh..

> We could do with a map that combines BPF_MAP_TYPE_HASH with the tails
> calls of BPF_MAP_TYPE_PROG_ARRAY.

Right, it'd complicate things but I think it's doable.

Thanks,
Namhyung

Re: [PATCH] perf trace: Increase syscall handler map size to 1024

[Ian Rogers]

On Tue, May 20, 2025 at 3:14 PM Namhyung Kim <namhyung@kernel.org> wrote:
>
> Hi Ian,
>
> On Tue, May 20, 2025 at 08:05:37AM -0700, Ian Rogers wrote:
> > On Mon, May 19, 2025 at 4:36 PM Howard Chu <howardchu95@gmail.com> wrote:
> > >
> > > Hello Namhyung,
> > >
> > > On Mon, May 19, 2025 at 4:25 PM Namhyung Kim <namhyung@kernel.org> wrote:
> > > >
> > > > The syscalls_sys_{enter,exit} map in augmented_raw_syscalls.bpf.c has
> > > > max entries of 512.  Usually syscall numbers are smaller than this but
> > > > x86 has x32 ABI where syscalls start from 512.
> > > >
> > > > That makes trace__init_syscalls_bpf_prog_array_maps() fail in the middle
> > > > of the loop when it accesses those keys.  As the loop iteration is not
> > > > ordered by syscall numbers anymore, the failure can affect non-x32
> > > > syscalls.
> > > >
> > > > Let's increase the map size to 1024 so that it can handle those ABIs
> > > > too.  While most systems won't need this, increasing the size will be
> > > > safer for potential future changes.
> >
> > Do we need to worry about MIPS where syscalls can be offset by 1000s?
> > https://lore.kernel.org/lkml/8ed7dfb2-1e4d-4aa4-a04b-0397a89365d1@app.fastmail.com/
>
> Argh..
>
> > We could do with a map that combines BPF_MAP_TYPE_HASH with the tails
> > calls of BPF_MAP_TYPE_PROG_ARRAY.
>
> Right, it'd complicate things but I think it's doable.

Should we merge the x32 fix while waiting for the hash fix?

Thanks,
Ian