linux-kernel - Re: [PATCH v8] PCI: hotplug: Add a generic RAS tracepoint for hotplug event

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: <aCxdFm_BpgOTFFUv@wunner.de>
Date: Tue, 20 May 2025 12:44:38 +0200
From: Lukas Wunner <lukas@...ner.de>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: Shuai Xue <xueshuai@...ux.alibaba.com>, rostedt@...dmis.org,
	linux-pci@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	linux-edac@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
	helgaas@...nel.org, 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 v8] PCI: hotplug: Add a generic RAS tracepoint for
 hotplug event

On Tue, May 20, 2025 at 01:07:28PM +0300, Ilpo Järvinen wrote:
> On Tue, 20 May 2025, Shuai Xue wrote:
> > , and the format of "Link Speed changed" is a bit different from 
> > "pci_hp_event".
> 
> The difference is only because when the Link is down, there's no Link
> Speed (obviously). Whenever a new device is hotplugged and it comes up, 
> there's also Link Speed for it which can be included into the trace event. 
> 
> I think the trace event should have some special value for the fields that 
> are N/A due to Link being off. While it would be possible to create 
> separate events for speed changes and hotplug, I don't see any pros in 
> that approach over just having the N/A fields marked as such when the Link 
> is Down.

Link speed changes and device plug/unplug events are orthogonal,
I don't think they should be mixed together in the same event.

A link speed event can be signaled simultaneously to a plug event
and then user space can decide in which type of event it's
interested in.

That also avoids the awkwardness of having N/A values for the
link speed on unplug.

Thanks,

Lukas