tools/perf/util/bpf_skel/augmented_raw_syscalls.bpf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
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
On Mon, 19 May 2025 16:25:39 -0700, Namhyung Kim 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.
>
> [...]
Applied to perf-tools-next, thanks!
Best regards,
Namhyung
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
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
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
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
On Thu, Aug 21, 2025 at 9:45 AM Ian Rogers <irogers@google.com> wrote:
>
> 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?
Just a reminder that this is still not resolved.
Thanks,
Ian
On Mon, Oct 13, 2025 at 1:22 PM Ian Rogers <irogers@google.com> wrote:
>
> On Thu, Aug 21, 2025 at 9:45 AM Ian Rogers <irogers@google.com> wrote:
> >
> > 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?
>
> Just a reminder that this is still not resolved.
Ping.
Thanks,
Ian
On Thu, Oct 30, 2025 at 01:47:55PM -0700, Ian Rogers wrote:
> On Mon, Oct 13, 2025 at 1:22 PM Ian Rogers <irogers@google.com> wrote:
> >
> > On Thu, Aug 21, 2025 at 9:45 AM Ian Rogers <irogers@google.com> wrote:
> > >
> > > 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?
> >
> > Just a reminder that this is still not resolved.
What do you mean by the x32 fix?
Thanks,
Namhyung
On Fri, Oct 31, 2025 at 12:08 PM Namhyung Kim <namhyung@kernel.org> wrote:
>
> On Thu, Oct 30, 2025 at 01:47:55PM -0700, Ian Rogers wrote:
> > On Mon, Oct 13, 2025 at 1:22 PM Ian Rogers <irogers@google.com> wrote:
> > >
> > > On Thu, Aug 21, 2025 at 9:45 AM Ian Rogers <irogers@google.com> wrote:
> > > >
> > > > 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?
> > >
> > > Just a reminder that this is still not resolved.
>
> What do you mean by the x32 fix?
This patch is the x32 fix. Your commit message says:
"Usually syscall numbers are smaller than this but x86 has x32 ABI
where syscalls start from 512."
We started discussing a hash table based fix because of MIPS, etc.
Thanks,
Ian
> Thanks,
> Namhyung
>
On Fri, Oct 31, 2025 at 12:25:41PM -0700, Ian Rogers wrote:
> On Fri, Oct 31, 2025 at 12:08 PM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > On Thu, Oct 30, 2025 at 01:47:55PM -0700, Ian Rogers wrote:
> > > On Mon, Oct 13, 2025 at 1:22 PM Ian Rogers <irogers@google.com> wrote:
> > > >
> > > > On Thu, Aug 21, 2025 at 9:45 AM Ian Rogers <irogers@google.com> wrote:
> > > > >
> > > > > 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?
> > > >
> > > > Just a reminder that this is still not resolved.
> >
> > What do you mean by the x32 fix?
>
> This patch is the x32 fix. Your commit message says:
> "Usually syscall numbers are smaller than this but x86 has x32 ABI
> where syscalls start from 512."
Oh, you meant this patch. :)
>
> We started discussing a hash table based fix because of MIPS, etc.
Right, I'll merge this as an interim solution.
Thanks,
Namhyung
© 2016 - 2025 Red Hat, Inc.