> On Jan 11, 2024, at 3:49 PM, Daniel Xu <dxu@xxxxxxxxx> wrote:
>
> 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.
This is an interesting idea. Thanks for the suggestion!
Song
