linux-kernel - RE: [PATCH 1/1] tracing: Support reading trace event format file larger than PAGE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b108b7edec16444ab04da770c796c60c@huawei.com>
Date: Tue, 7 Jan 2025 11:04:57 +0000
From: Shiju Jose <shiju.jose@...wei.com>
To: Steven Rostedt <rostedt@...dmis.org>
CC: "mhiramat@...nel.org" <mhiramat@...nel.org>,
	"mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>,
	"linux-trace-kernel@...r.kernel.org" <linux-trace-kernel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Linuxarm
	<linuxarm@...wei.com>, Jonathan Cameron <jonathan.cameron@...wei.com>,
	tanxiaofei <tanxiaofei@...wei.com>, "Zengtao (B)" <prime.zeng@...ilicon.com>
Subject: RE: [PATCH 1/1] tracing: Support reading trace event format file
 larger than PAGE_SIZE

>-----Original Message-----
>From: Steven Rostedt <rostedt@...dmis.org>
>Sent: 06 January 2025 22:12
>To: Shiju Jose <shiju.jose@...wei.com>
>Cc: mhiramat@...nel.org; mathieu.desnoyers@...icios.com; linux-trace-
>kernel@...r.kernel.org; linux-kernel@...r.kernel.org; Linuxarm
><linuxarm@...wei.com>; Jonathan Cameron
><jonathan.cameron@...wei.com>; tanxiaofei <tanxiaofei@...wei.com>;
>Zengtao (B) <prime.zeng@...ilicon.com>
>Subject: Re: [PATCH 1/1] tracing: Support reading trace event format file larger
>than PAGE_SIZE
>
>On Mon, 6 Jan 2025 18:15:36 +0000
>Shiju Jose <shiju.jose@...wei.com> wrote:
>
>> >You see, it requires multiple reads to pull in an entire kernel
>> >pseudo file. None of those reads are greater than PAGE_SIZE. Why
>> >should trace format files be any different?
>> Thanks for the reply.
>> Yes. I had a fix/workaround in the userspace rasdaemon with multiple
>> reads like above as reported previously in the  following thread.
>> https://lore.kernel.org/lkml/3c9808a694d242cab35bab67602edebf@huawei.c
>> om/ However thought a solution in the common kernel code for the
>> format file may be better.  I will go ahead with the user space
>> solution.
>
>That would make it different than every other pseudo file in the kernel. I rather
>not do that.
>
>>
>> Also shared an information in the above thread about libtraceevent
>> __parse_event() does not return error when parse_format() fail with
>> incomplete formt data, which resulted initialization for the trace event does
>not fail in the user space tool.
>
>Hmm, can you send me the the format file that failed?
>
>Just the output of "cat /sys/kernel/tracing/events/<system>/<event>/format"
>will do.

Please find attached format file, which might have failed to parse because of the
unsupported formats in the libtraceevent you mentioned in the following thread.
https://lore.kernel.org/lkml/20241127104132.6c1729e1@gandalf.local.home/#t    

Please find the improvement in the libraceevent which I mentioned for not returning error
when parsing failed,
===========================================
diff --git a/src/event-parse.c b/src/event-parse.c index 0427061..b9264cb 100644
--- a/src/event-parse.c
+++ b/src/event-parse.c
@@ -7905,9 +7905,14 @@ __parse_event(struct tep_handle *tep,
              const char *buf, unsigned long size,
              const char *sys)
 {
-       int ret = parse_format(eventp, tep, buf, size, sys);
-       struct tep_event *event = *eventp;
+       int ret;
+       struct tep_event *event;
+
+       ret = parse_format(eventp, tep, buf, size, sys);
+       if (ret)
+               return ret;
 
+       event = *eventp;
        if (event == NULL)
                return ret; 
 =========================================  
>
>-- Steve

Thanks,
Shiju

Download attachment "format_cxl_general_media" of type "application/octet-stream" (5089 bytes)