On Fri, Oct 27, 2023 at 7:24 AM Song Liu <songliubraving@xxxxxxxx> wrote:
>
>
>
> > On Oct 27, 2023, at 6:56 AM, Jiri Olsa <olsajiri@xxxxxxxxx> wrote:
> >
> > On Thu, Oct 26, 2023 at 09:31:00AM -0700, Song Liu wrote:
> >> On Wed, Oct 25, 2023 at 1:24 PM Jiri Olsa <jolsa@xxxxxxxxxx> wrote:
> >>>
> >>> We will need to return ref_ctr_offsets values through link_info
> >>> interface in following change, so we need to keep them around.
> >>>
> >>> Storing ref_ctr_offsets values directly into bpf_uprobe array.
> >>>
> >>> Signed-off-by: Jiri Olsa <jolsa@xxxxxxxxxx>
> >>
> >> Acked-by: Song Liu <song@xxxxxxxxxx>
> >>
> >> with one nitpick below.
> >>
> >>> ---
> >>> kernel/trace/bpf_trace.c | 14 +++-----------
> >>> 1 file changed, 3 insertions(+), 11 deletions(-)
> >>>
> >>> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> >>> index df697c74d519..843b3846d3f8 100644
> >>> --- a/kernel/trace/bpf_trace.c
> >>> +++ b/kernel/trace/bpf_trace.c
> >>> @@ -3031,6 +3031,7 @@ struct bpf_uprobe_multi_link;
> >>> struct bpf_uprobe {
> >>> struct bpf_uprobe_multi_link *link;
> >>> loff_t offset;
> >>> + unsigned long ref_ctr_offset;
> >>
> >> nit: s/unsigned long/loff_t/ ?
> >
> > hum, the single uprobe interface also keeps it as 'unsigned long'
> > in 'struct trace_uprobe' .. while uprobe code keeps both offset and
> > ref_ctr_offset values as loff_t
> >
> > is there any benefit by changing that to loff_t?
>
> We have "loff_t offset;" right above this line. So it is better to
> use same type for the two offsets.
but user is providing it as `unsigned long *` array, so instead of
relying on loff_t being the same as unsigned long, let's just keep the
original data type?
>
> Thanks,
> Song
>
