Re: [PATCH bpf-next v4 5/8] bpf: Update per-CPU maps using BPF_F_ALL_CPUS flag

[Leon Hwang <leon.hwang@linux.dev>]

On 2026/4/17 09:33, Leon Hwang wrote:
> On 15/4/26 10:21, Alexei Starovoitov wrote:
>> On Tue, Apr 14, 2026 at 09:24:17PM +0800, Leon Hwang wrote:
>>> When updating per-CPU maps via the lightweight skeleton loader, use
>>> a single value slot across all CPUs. This avoids two potential issues
>>> when updating on an M-CPU kernel with N cached slots (N < M), especially
>>> when N is much smaller than M:
>>>
>>> 1) The update may trigger a page fault when copying data from the last
>>>    slot, as the read may go beyond the allocated buffer.
>>> 2) The update may copy unexpected data from slots [N, M-1].
>>>
>>> Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
>>> ---
>>>  kernel/bpf/syscall.c | 15 +++++++++++++++
>>>  1 file changed, 15 insertions(+)
>>>
>>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>>> index b73b25c63073..f0f3785ef57d 100644
>>> --- a/kernel/bpf/syscall.c
>>> +++ b/kernel/bpf/syscall.c
>>> @@ -1785,6 +1785,21 @@ static int map_update_elem(union bpf_attr *attr, bpfptr_t uattr)
>>>  		goto err_put;
>>>  	}
>>>  
>>> +	/*
>>> +	 * When updating per-CPU maps via the lightweight skeleton
>>> +	 * loader, use a single value slot across all CPUs. This avoids
>>> +	 * two potential issues when updating on an M-CPU kernel with
>>> +	 * N cached slots (N < M), especially when N is much smaller
>>> +	 * than M:
>>> +	 * 1) The update may trigger a page fault when copying data from
>>> +	 *    the last slot, as the read may go beyond the allocated
>>> +	 *    buffer.
>>> +	 * 2) The update may copy unexpected data from slots [N, M-1].
>>> +	 */
>>> +	if (bpfptr_is_kernel(uattr) && bpf_map_supports_cpu_flags(map->map_type) &&
>>> +	    !(attr->flags & (BPF_F_CPU | BPF_F_ALL_CPUS)))
>>> +		attr->flags |= BPF_F_ALL_CPUS;
>>
>> This looks like a hack. It's not addressing the actual bug.
>> If there is a bug submit it separately with fixes tag.
> 
> Sure, will verify whether it is a bug. If it is, will fix it with
> separate patch.
> 

By implementing two selftests [1] against syscall progs and lightweight
skeleton, it is not a real issue.

The assuming oob reading might occur when updating percpu_array map
using a small value buffer for syscall progs. However, the oob reading
won't make kernel panic, because copy kernel memory using
copy_from_kernel_nofault(). However, as for lskel, the oob reading
doesn't occur, even set value size as 32000 and update percpu_array map
using an int.

The assuming issue #2 that copies unexpected data is true for both
syscall progs and lskel. However, I think it's users' responsibility to
correctly update percpu_array map using big enough value data.

In conclusion, I'll drop this patch from this series, and won't send
separate patch because it is not a bug.

[1] https://github.com/Asphaltt/bpf/commits/bpf/lskel-oob/v1/

Thanks,
Leon