From: Song Liu <songliubraving@fb.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
CC: Peter Zijlstra <peterz@infradead.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        "mingo@redhat.com" <mingo@redhat.com>,
        David Miller <davem@davemloft.net>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "daniel@iogearbox.net" <daniel@iogearbox.net>,
        Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH v3 1/6] perf: prepare perf_event.h for new types
 perf_kprobe and perf_uprobe
Thread-Topic: [PATCH v3 1/6] perf: prepare perf_event.h for new types
 perf_kprobe and perf_uprobe
Thread-Index: AQHTajYQKJbJFCkg5UmzbkvzfKlS6qMx3MoAgAGpKwA=
Date: Mon, 4 Dec 2017 18:24:59 +0000
Message-ID: <D0757E13-27E8-4392-972A-399D6E132111@fb.com>
References: <20171130235023.1414663-1-songliubraving@fb.com>
 <20171130235023.1414663-4-songliubraving@fb.com>
 <20171203170312.rvjo6ifl2pgpjkcs@ast-mbp>
In-Reply-To: <20171203170312.rvjo6ifl2pgpjkcs@ast-mbp>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7A3C3E4CB1C17341929F637C488F1448@namprd15.prod.outlook.com>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 30f90da5-215e-4e38-6345-08d53b4453b5
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2017 18:24:59.0223
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1509
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-04_06:,,
 signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id vB4IPvRp017584
Content-Length: 2264
Lines: 53


> On Dec 3, 2017, at 9:03 AM, Alexei Starovoitov <alexei.starovoitov@gmail.com> 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 <songliubraving@fb.com>
>> Reviewed-by: Yonghong Song <yhs@fb.com>
>> Reviewed-by: Josef Bacik <jbacik@fb.com>
>> Acked-by: Alexei Starovoitov <ast@kernel.org>
>> ---
>> 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