Re: [PATCH] perf trace: Refactor augmented_raw_syscalls using bpf_loop

[Namhyung Kim]

On Wed, Jul 01, 2026 at 08:12:06AM +0200, Viktor Malik wrote:
> On 6/30/26 07:42, Viktor Malik wrote:
> > On 6/29/26 22:35, Namhyung Kim wrote:
> >> On Thu, Jun 25, 2026 at 02:05:29PM +0200, Viktor Malik wrote:
> >>> On 6/24/26 21:24, Namhyung Kim wrote:
> >>>> On Wed, Jun 24, 2026 at 08:47:38AM +0200, Viktor Malik wrote:
> >>>>> On 6/23/26 19:10, Namhyung Kim wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> On Tue, Jun 23, 2026 at 08:27:39AM -0700, Alexei Starovoitov wrote:
> >>>>>>> On Tue Jun 23, 2026 at 4:25 AM PDT, Viktor Malik wrote:
> >>>> [SNIP]
> >>>>>>>> +	struct args_loop_ctx loop_ctx = {
> >>>>>>>> +		.args = args,
> >>>>>>>> +		.beauty_map = beauty_map,
> >>>>>>>> +		.payload_offset = payload_offset,
> >>>>>>>> +		.value_size = value_size,
> >>>>>>>> +		.output = &output,
> >>>>>>>> +		.do_output = &do_output
> >>>>>>>> +	};
> >>>>>>>> +	iters = bpf_loop(6, process_arg_cb, &loop_ctx, 0);
> >>>>>>>
> >>>>>>> bpf_loop() is old and generally not recommended.
> >>>>>>> Please use bpf_for() then the diff will be one line change and
> >>>>>>> can scale to any number of args. Not just 6.
> >>>>>
> >>>>> Thanks Alexei, I didn't know about this preference.
> >>>>>
> >>>>>> One thing we should take care is to support old kernels.  The oldest
> >>>>>> LTS kernel in the kernel.org is 5.10 and bpf_loop() was introduced in
> >>>>>> 5.17 and bpf_for (bpf_iter_num) was 6.4.
> >>>>>
> >>>>> The problematic loop was introduced in 6.12 by a68fd6a6cdd3 ("perf
> >>>>> trace: Collect augmented data using BPF") so we should be good using
> >>>>> bpf_for. Or is perf from 7.2 supposed to work on 5.10 LTS kernels?
> >>>>
> >>>> Yep, we'd like to support old kernels.
> >>>
> >>> How much strict are you on this requirement? IMHO, the very least we
> >>> need to fix the verifier issue is bpf_loop, so that would still not work
> >>> on 5.10 and 5.15 LTS kernels.
> >>
> >> I don't think it's an absolute requirement, but I think we don't want to
> >> break any existing working setup (old kernel + old compiler).
> >>
> >>>
> >>> We could probably keep the open-coded loop in case bpf_loop is not
> >>> available but `perf trace` would still fail on kernels without bpf_loop
> >>> for new perf built with Clang>=22. Also, the code would be a bit ugly
> >>> and I'm not sure how well the feature check for helpers (bpf_loop) works
> >>> on old kernels.
> >>  
> >> Any chance process_arg_cb() can be called directly in the regular for
> >> loop on old kernels?
> > 
> > That's my thinking, too. Should be pretty straightforward, I'm going to
> > give it a try in v2.
> 
> Btw, I just noticed that util/bpf_skel/lock_contention.bpf.c already
> uses bpf_loop without any fallback so newer perf (at least `perf lock`)
> won't be usable on kernels without bpf_loop anyways.
 
IIUC the lock contention tracepoints were added to v5.19 so it won't
work on old kernels anyway. :)

Thanks,
Namhyung