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: <20250724222510.7b00ea79@gandalf.local.home>
Date: Thu, 24 Jul 2025 22:25:10 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Shuai Xue <xueshuai@...ux.alibaba.com>
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

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

-- Steve