On Thu, Jan 11, 2024 at 11:06:23PM +0000, Song Liu wrote:
>
>
> > On Jan 11, 2024, at 2:48 PM, Daniel Xu <dxu@xxxxxxxxx> wrote:
> >
> > Hi Song,
> >
> > On Thu, Jan 11, 2024 at 09:51:05PM +0000, Song Liu wrote:
> >> The problem
> >>
> >> Inlining can cause surprises to tracing users, especially when the tool
> >> appears to be working. For example, with
> >>
> >> [root@ ~]# bpftrace -e 'kprobe:switch_mm {}'
> >> Attaching 1 probe...
> >>
> >> The user may not realize switch_mm() is inlined by leave_mm(), and we are
> >> not tracing the code path leave_mm => switch_mm. (This is x86_64, and both
> >> functions are in arch/x86/mm/tlb.c.)
> >>
> >> We have folks working on ideas to create offline tools to detect such
> >> issues for critical use cases at compile time. However, I think it is
> >> necessary to handle it at program load/attach time.
> >
> > Could you clarify what offline means?
>
> The idea is to keep a list of kernel functions used by key services. At
> kernel build time, we check whether any of these functions are inlined.
> If so, the tool will catch it, and we need to add noinline to the function.
Neat idea!
> > I wonder if libbpf should just give a way for applications to query
> > inline status. Seems most flexible. And maybe also a special SEC() def?
>
> API to query inline status makes sense. What do we do with SEC()?
Oh, I meant that you could make the SEC() parser take for example:
SEC("kprobe.noinline/switch_mm")
or something like that. Rather than add flags to bpf_program which may
not be applicable to every program type.
[...]
Thanks,
Daniel
