[PATCH v2 3/4] bpf: allocate the buffers BPF map to fit highest CPU id

[PATCH v2 3/4] bpf: allocate the buffers BPF map to fit highest CPU id

[Kris Van Hees]

Even when less than the possible number of CPUs are online, the 'buffers'
BPF map should be allocated based on the highest possible CPU id because
probe data is written to the bufer that corresponds to a given CPU id,
which could be part of non-sequential CPU id configurations.

The observed problem was on a system with 128 possible CPUs (0-127), but
only CPUs 0-7,100-107 were online.  The 'buffers' BPF map was created with
space to hold 16 trace data buffers (one for each online CPU), and since it
is an array map, this caused the trace buffers for CPUs 100-107 to fail to
allocate buffers, which in turn caused any trace data generated for those
CPUs never to get reported.  Since 'buffers' is an array map accessed by
CPU id, enough space must be allocated to accomodate the highest online
CPU id.

Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
---
 libdtrace/dt_bpf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libdtrace/dt_bpf.c b/libdtrace/dt_bpf.c
index 0a57b7d2..6568a572 100644
--- a/libdtrace/dt_bpf.c
+++ b/libdtrace/dt_bpf.c
@@ -755,7 +755,7 @@ gmap_create_buffers(dtrace_hdl_t *dtp)
 {
 	return create_gmap(dtp, "buffers", BPF_MAP_TYPE_PERF_EVENT_ARRAY,
 			   sizeof(uint32_t), sizeof(uint32_t),
-			   dtp->dt_conf.num_online_cpus);
+			   dtp->dt_conf.max_cpuid);
 }
 
 /*
-- 
2.51.0

Re: [PATCH v2 3/4] bpf: allocate the buffers BPF map to fit highest CPU id

[Eugene Loh]

  Reviewed-by: Eugene Loh <eugene.loh@oracle.com>

On 12/17/25 00:10, Kris Van Hees wrote:
> Even when less than the possible number of CPUs are online, the 'buffers'
> BPF map should be allocated based on the highest possible CPU id because
> probe data is written to the bufer that corresponds to a given CPU id,
> which could be part of non-sequential CPU id configurations.
>
> The observed problem was on a system with 128 possible CPUs (0-127), but
> only CPUs 0-7,100-107 were online.  The 'buffers' BPF map was created with
> space to hold 16 trace data buffers (one for each online CPU), and since it
> is an array map, this caused the trace buffers for CPUs 100-107 to fail to
> allocate buffers, which in turn caused any trace data generated for those
> CPUs never to get reported.  Since 'buffers' is an array map accessed by
> CPU id, enough space must be allocated to accomodate the highest online
> CPU id.
>
> Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
> ---
>   libdtrace/dt_bpf.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libdtrace/dt_bpf.c b/libdtrace/dt_bpf.c
> index 0a57b7d2..6568a572 100644
> --- a/libdtrace/dt_bpf.c
> +++ b/libdtrace/dt_bpf.c
> @@ -755,7 +755,7 @@ gmap_create_buffers(dtrace_hdl_t *dtp)
>   {
>   	return create_gmap(dtp, "buffers", BPF_MAP_TYPE_PERF_EVENT_ARRAY,
>   			   sizeof(uint32_t), sizeof(uint32_t),
> -			   dtp->dt_conf.num_online_cpus);
> +			   dtp->dt_conf.max_cpuid);
>   }
>   
>   /*

Re: [PATCH v2 3/4] bpf: allocate the buffers BPF map to fit highest CPU id

[Kris Van Hees]

On Thu, Dec 18, 2025 at 03:10:32PM -0500, Eugene Loh wrote:
>  Reviewed-by: Eugene Loh <eugene.loh@oracle.com>

Per your reporting on the 2/4 patch, and further testing, the array map needs
to be created with size max_cpuid + 1 to accomodate the CPU with the highest
id (max_cpuid).  I made that change in the patch and it resolves the issues
with tests.

If you agree, I can just make that change in the patch, retain your R-b, and
merge.  Let me know...

> On 12/17/25 00:10, Kris Van Hees wrote:
> > Even when less than the possible number of CPUs are online, the 'buffers'
> > BPF map should be allocated based on the highest possible CPU id because
> > probe data is written to the bufer that corresponds to a given CPU id,
> > which could be part of non-sequential CPU id configurations.
> > 
> > The observed problem was on a system with 128 possible CPUs (0-127), but
> > only CPUs 0-7,100-107 were online.  The 'buffers' BPF map was created with
> > space to hold 16 trace data buffers (one for each online CPU), and since it
> > is an array map, this caused the trace buffers for CPUs 100-107 to fail to
> > allocate buffers, which in turn caused any trace data generated for those
> > CPUs never to get reported.  Since 'buffers' is an array map accessed by
> > CPU id, enough space must be allocated to accomodate the highest online
> > CPU id.
> > 
> > Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
> > ---
> >   libdtrace/dt_bpf.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libdtrace/dt_bpf.c b/libdtrace/dt_bpf.c
> > index 0a57b7d2..6568a572 100644
> > --- a/libdtrace/dt_bpf.c
> > +++ b/libdtrace/dt_bpf.c
> > @@ -755,7 +755,7 @@ gmap_create_buffers(dtrace_hdl_t *dtp)
> >   {
> >   	return create_gmap(dtp, "buffers", BPF_MAP_TYPE_PERF_EVENT_ARRAY,
> >   			   sizeof(uint32_t), sizeof(uint32_t),
> > -			   dtp->dt_conf.num_online_cpus);
> > +			   dtp->dt_conf.max_cpuid);
> >   }
> >   /*

Re: [PATCH v2 3/4] bpf: allocate the buffers BPF map to fit highest CPU id

[Eugene Loh]

On 1/7/26 09:19, Kris Van Hees wrote:

> On Thu, Dec 18, 2025 at 03:10:32PM -0500, Eugene Loh wrote:
>>   Reviewed-by: Eugene Loh <eugene.loh@oracle.com>
> Per your reporting on the 2/4 patch, and further testing, the array map needs
> to be created with size max_cpuid + 1 to accomodate the CPU with the highest
> id (max_cpuid).  I made that change in the patch and it resolves the issues
> with tests.
>
> If you agree, I can just make that change in the patch, retain your R-b, and
> merge.  Let me know...

Yes, I agree.

>> On 12/17/25 00:10, Kris Van Hees wrote:
>>> Even when less than the possible number of CPUs are online, the 'buffers'
>>> BPF map should be allocated based on the highest possible CPU id because
>>> probe data is written to the bufer that corresponds to a given CPU id,
>>> which could be part of non-sequential CPU id configurations.
>>>
>>> The observed problem was on a system with 128 possible CPUs (0-127), but
>>> only CPUs 0-7,100-107 were online.  The 'buffers' BPF map was created with
>>> space to hold 16 trace data buffers (one for each online CPU), and since it
>>> is an array map, this caused the trace buffers for CPUs 100-107 to fail to
>>> allocate buffers, which in turn caused any trace data generated for those
>>> CPUs never to get reported.  Since 'buffers' is an array map accessed by
>>> CPU id, enough space must be allocated to accomodate the highest online
>>> CPU id.
>>>
>>> Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
>>> ---
>>>    libdtrace/dt_bpf.c | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libdtrace/dt_bpf.c b/libdtrace/dt_bpf.c
>>> index 0a57b7d2..6568a572 100644
>>> --- a/libdtrace/dt_bpf.c
>>> +++ b/libdtrace/dt_bpf.c
>>> @@ -755,7 +755,7 @@ gmap_create_buffers(dtrace_hdl_t *dtp)
>>>    {
>>>    	return create_gmap(dtp, "buffers", BPF_MAP_TYPE_PERF_EVENT_ARRAY,
>>>    			   sizeof(uint32_t), sizeof(uint32_t),
>>> -			   dtp->dt_conf.num_online_cpus);
>>> +			   dtp->dt_conf.max_cpuid);
>>>    }
>>>    /*