linux-kernel - Re: [PATCH v9 2/2] PCI: trace: Add a RAS tracepoint to monitor link speed changes

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: <d87b1029-b572-4995-82a9-c7d83551900e@linux.alibaba.com>
Date: Fri, 25 Jul 2025 10:59:16 +0800
From: Shuai Xue <xueshuai@...ux.alibaba.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: lukas@...ner.de, linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-edac@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 helgaas@...nel.org, ilpo.jarvinen@...ux.intel.com, mattc@...estorage.com,
 Jonathan.Cameron@...wei.com, bhelgaas@...gle.com, tony.luck@...el.com,
 bp@...en8.de, mhiramat@...nel.org, mathieu.desnoyers@...icios.com,
 oleg@...hat.com, naveen@...nel.org, davem@...emloft.net,
 anil.s.keshavamurthy@...el.com, mark.rutland@....com, peterz@...radead.org,
 tianruidong@...ux.alibaba.com
Subject: Re: [PATCH v9 2/2] PCI: trace: Add a RAS tracepoint to monitor link
 speed changes



在 2025/7/25 10:25, Steven Rostedt 写道:
> On Fri, 25 Jul 2025 10:11:10 +0800
> Shuai Xue <xueshuai@...ux.alibaba.com> wrote:
> 
>> For the libtraceevent implementation, I believe we'd
>> need to:
>>
>> - Add the PCI speed mapping table to libtraceevent
>> - Create a print function similar to other existing parsers
>> - Ensure perf, trace-cmd, and rasdaemon can all benefit from it
>>
>> Would you like me to investigate the libtraceevent changes, or do you
> 
> Yeah, just update libtraceevent. In fact, libtraceevent has plugins for
> things like this.
> 
> You can use this as an example:
> 
>    https://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git/tree/plugins/plugin_jbd2.c
> 
> That adds two functions that are used in print fmt strings. Here's one:
> 
> static unsigned long long
> process_jbd2_dev_to_name(struct trace_seq *s, unsigned long long *args)
> {
> 	unsigned int dev = args[0];
> 
> 	trace_seq_printf(s, "%d:%d", MAJOR(dev), MINOR(dev));
> 	return 0;
> }
> 
> 
> int TEP_PLUGIN_LOADER(struct tep_handle *tep)
> {
> 	tep_register_print_function(tep,
> 				    process_jbd2_dev_to_name,
> 				    TEP_FUNC_ARG_STRING,
> 				    "jbd2_dev_to_name",
> 				    TEP_FUNC_ARG_INT,
> 				    TEP_FUNC_ARG_VOID);
> [..]
> 
> The above defines:
> 
> 	char *jbd2_dev_to_name(int arg0);
> 
> And when this is found in the parsing, it calls process_jbd2_dev_to_name()
> passing it the arguments that was found in the trace.
> 
> You would have something like:
> 
> 	tep_register_print_function(tep,
> 				    process_pci_speed_string,
> 				    TEP_FUNC_ARG_STRING,
> 				    "pci_speed_string",
> 				    TEP_FUNC_ARG_INT,
> 				    TEP_FUNC_ARG_VOID);
> 
> Which will return a string and take an integer as an argument. Then you
> would just implement the process_pci_speed_string() function to do the same
> thing as the pci_speed_string() does in the kernel.
> 
> Oh, and here's the man page for you on tep_register_print_function()
> 
>    https://trace-cmd.org/Documentation/libtraceevent/libtraceevent-reg_print_func.html

Hi Steve,

Thank you so much for the detailed guidance and the excellent example!
This makes it much clearer how to implement the libtraceevent support.

Should I include the libtraceevent plugin patch in the same kernel patch
series, or submit it separately? I'm not sure about the best practice
here.

> 
> -- Steve

I'll work on the libtraceevent patch and submit it according to your
guidance. Thanks again for the clear direction and the documentation
link!

Thanks.
Shuai