On Thu, Nov 30, 2017 at 03:50:18PM -0800, Song Liu wrote:
> Two new perf types, perf_kprobe and perf_uprobe, will be added to allow
> creating [k,u]probe with perf_event_open. These [k,u]probe are associated
> with the file decriptor created by perf_event_open, thus are easy to
> clean when the file descriptor is destroyed.
>
> kprobe_func and uprobe_path are added to union config1 for pointers to
> function name for kprobe or binary path for uprobe.
>
> kprobe_addr and probe_offset are added to union config2 for kernel
> address (when kprobe_func is NULL), or [k,u]probe offset.
>
> Signed-off-by: Song Liu <[email protected]>
> Reviewed-by: Yonghong Song <[email protected]>
> Reviewed-by: Josef Bacik <[email protected]>
> Acked-by: Alexei Starovoitov <[email protected]>
> ---
> include/uapi/linux/perf_event.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 362493a..247c6cb 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -299,6 +299,8 @@ enum perf_event_read_format {
> #define PERF_ATTR_SIZE_VER4 104 /* add: sample_regs_intr */
> #define PERF_ATTR_SIZE_VER5 112 /* add: aux_watermark */
>
> +#define MAX_PROBE_FUNC_NAME_LEN 64
I think we have to remove this restriction.
There are already functions with names longer than 64 characters
in the current vmlinux:
trace_event_define_fields_ext4_ext_convert_to_initialized_fastpath
trace_event_define_fields_mm_vmscan_direct_reclaim_begin_template
How about we drop this restriction and use NAME_MAX internally
without adding new uapi defines ?
> On Dec 3, 2017, at 9:03 AM, Alexei Starovoitov <[email protected]> wrote:
>
> On Thu, Nov 30, 2017 at 03:50:18PM -0800, Song Liu wrote:
>> Two new perf types, perf_kprobe and perf_uprobe, will be added to allow
>> creating [k,u]probe with perf_event_open. These [k,u]probe are associated
>> with the file decriptor created by perf_event_open, thus are easy to
>> clean when the file descriptor is destroyed.
>>
>> kprobe_func and uprobe_path are added to union config1 for pointers to
>> function name for kprobe or binary path for uprobe.
>>
>> kprobe_addr and probe_offset are added to union config2 for kernel
>> address (when kprobe_func is NULL), or [k,u]probe offset.
>>
>> Signed-off-by: Song Liu <[email protected]>
>> Reviewed-by: Yonghong Song <[email protected]>
>> Reviewed-by: Josef Bacik <[email protected]>
>> Acked-by: Alexei Starovoitov <[email protected]>
>> ---
>> include/uapi/linux/perf_event.h | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
>> index 362493a..247c6cb 100644
>> --- a/include/uapi/linux/perf_event.h
>> +++ b/include/uapi/linux/perf_event.h
>> @@ -299,6 +299,8 @@ enum perf_event_read_format {
>> #define PERF_ATTR_SIZE_VER4 104 /* add: sample_regs_intr */
>> #define PERF_ATTR_SIZE_VER5 112 /* add: aux_watermark */
>>
>> +#define MAX_PROBE_FUNC_NAME_LEN 64
>
> I think we have to remove this restriction.
> There are already functions with names longer than 64 characters
> in the current vmlinux:
> trace_event_define_fields_ext4_ext_convert_to_initialized_fastpath
> trace_event_define_fields_mm_vmscan_direct_reclaim_begin_template
>
> How about we drop this restriction and use NAME_MAX internally
> without adding new uapi defines ?
Yeah, I agree that we should drop this uapi define. How about we use
#define KSYM_NAME_LEN 128
If a function name is longer than KSYM_NAME_LEN, we get warning like:
Symbol long_long_name_abcdefghijklmnopqrstuvwxyz_abcdefghijklmnopqrstuvwxyz_abcdefghijklmnopqrstuvwxyz_abcdefghijklmnopqrstuvwxyz_abcdefghijklmnopqrstuvwxyz_abcdefghijklmnopqrstuvwxyz_abcdefghijklmnopqrstuvwxyz_ too long for kallsyms (204 vs 128).
Please increase KSYM_NAME_LEN both in kernel and kallsyms.c
Thanks,
Song
On 12/4/17 10:24 AM, Song Liu wrote:
>
>> On Dec 3, 2017, at 9:03 AM, Alexei Starovoitov <[email protected]> wrote:
>>
>> On Thu, Nov 30, 2017 at 03:50:18PM -0800, Song Liu wrote:
>>> Two new perf types, perf_kprobe and perf_uprobe, will be added to allow
>>> creating [k,u]probe with perf_event_open. These [k,u]probe are associated
>>> with the file decriptor created by perf_event_open, thus are easy to
>>> clean when the file descriptor is destroyed.
>>>
>>> kprobe_func and uprobe_path are added to union config1 for pointers to
>>> function name for kprobe or binary path for uprobe.
>>>
>>> kprobe_addr and probe_offset are added to union config2 for kernel
>>> address (when kprobe_func is NULL), or [k,u]probe offset.
>>>
>>> Signed-off-by: Song Liu <[email protected]>
>>> Reviewed-by: Yonghong Song <[email protected]>
>>> Reviewed-by: Josef Bacik <[email protected]>
>>> Acked-by: Alexei Starovoitov <[email protected]>
>>> ---
>>> include/uapi/linux/perf_event.h | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
>>> index 362493a..247c6cb 100644
>>> --- a/include/uapi/linux/perf_event.h
>>> +++ b/include/uapi/linux/perf_event.h
>>> @@ -299,6 +299,8 @@ enum perf_event_read_format {
>>> #define PERF_ATTR_SIZE_VER4 104 /* add: sample_regs_intr */
>>> #define PERF_ATTR_SIZE_VER5 112 /* add: aux_watermark */
>>>
>>> +#define MAX_PROBE_FUNC_NAME_LEN 64
>>
>> I think we have to remove this restriction.
>> There are already functions with names longer than 64 characters
>> in the current vmlinux:
>> trace_event_define_fields_ext4_ext_convert_to_initialized_fastpath
>> trace_event_define_fields_mm_vmscan_direct_reclaim_begin_template
>>
>> How about we drop this restriction and use NAME_MAX internally
>> without adding new uapi defines ?
>
> Yeah, I agree that we should drop this uapi define. How about we use
>
> #define KSYM_NAME_LEN 128
>
> If a function name is longer than KSYM_NAME_LEN, we get warning like:
>
> Symbol long_long_name_abcdefghijklmnopqrstuvwxyz_abcdefghijklmnopqrstuvwxyz_abcdefghijklmnopqrstuvwxyz_abcdefghijklmnopqrstuvwxyz_abcdefghijklmnopqrstuvwxyz_abcdefghijklmnopqrstuvwxyz_abcdefghijklmnopqrstuvwxyz_ too long for kallsyms (204 vs 128).
> Please increase KSYM_NAME_LEN both in kernel and kallsyms.c
right. that's better.
Thanks