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: <25285fbd-ffab-49e5-a8be-e3a1c8e70d3c@linux.alibaba.com>
Date: Mon, 21 Jul 2025 21:17:55 +0800
From: Shuai Xue <xueshuai@...ux.alibaba.com>
To: Lukas Wunner <lukas@...ner.de>, Bjorn Helgaas <helgaas@...nel.org>,
 Matthew W Carlis <mattc@...estorage.com>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: anil.s.keshavamurthy@...el.com, bhelgaas@...gle.com, bp@...en8.de,
 davem@...emloft.net, linux-edac@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, mark.rutland@....com,
 mathieu.desnoyers@...icios.com, mhiramat@...nel.org, naveen@...nel.org,
 oleg@...hat.com, peterz@...radead.org, rostedt@...dmis.org,
 tianruidong@...ux.alibaba.com, tony.luck@...el.com
Subject: Re: [PATCH v8] PCI: hotplug: Add a generic RAS tracepoint for hotplug
 event



在 2025/7/19 15:11, Lukas Wunner 写道:
> On Sat, Jul 19, 2025 at 01:23:28PM +0800, Shuai Xue wrote:
>>             <...>-120     [002] .....   104.864051: pci_hp_event: 0000:00:03.0 slot:30, event:PCI_HOTPLUG_CARD_PRESENT
>>             <...>-120     [002] .....   104.864081: pci_hp_event: 0000:00:03.0 slot:30, event:PCI_HOTPLUG_LINK_UP
> 
> Somehow I liked the simple "Link Up" and "Card present" strings more
> than this. :)
> 
> The PCI_HOTPLUG substring repeats what pci_hp_event already betrays,
> that this is a hotplug event.

I think Bjorn's concern is mainly about parsing issues when strings
contain spaces.

So, how about using "Link_UP" and "Card_Present" instead?

> 
>>     irq/57-pciehp-120     [002] .....   104.990434: pci_link_event: 0000:00:03.0 cur_bus_speed:20, max_bus_speed:23, width:1, flit_mode:0, reason:5
>>     irq/57-pciehp-120     [002] .....   104.992377: pci_link_event: 0000:00:03.0 cur_bus_speed:20, max_bus_speed:23, width:1, flit_mode:0, reason:0
> 
> This contains a lot of terminology specific to PCI *Express*
> (versus Conventional PCI or PCI-X).  Either it needs to be
> "pcie_link_event" or we need to come up with a structure that
> works for non-PCIe as well.
> 

I see, I will rename it to pcie_link_event.

> PCI links can be tunneled over Thunderbolt, in this case the
> link speed is fixed to 2.5 GT/s (USB4 v1.0 sec 11.2.1), but
> in reality is governed by the speed of the Thunderbolt fabric
> (which can even be asymmetric).  Do we want to report the
> virtual 2.5 GT/s in this case or the actual Thunderbolt speed?
> Or do we want a separate trace event for Thunderbolt?

I'm not a user of Thunderbolt, which way do you prefer?

> 
> For Root and Downstream Ports, the physical "port" points "downstream",
> whereas for Upstream Ports and Endpoints, the physical "port" points
> "upstream".  Software interpreting the trace event may want to know
> the direction (or whatever one wants to call it) because it cannot
> tell from the address 0000:00:03.0 what the PCIe type is.  Having to
> look this up in lspci seems cumbersome.  So it may be worthwhile to
> include either the port's direction or the device's PCIe type in the
> trace event.
> 
> Of course, hotplug only exists at Root or Downstream Ports, so any
> trace event generated from the PCIe hotplug driver will pertain to
> a downstream-facing port.  But the bandwidth controller also binds
> to Upstream Ports and its trace events may thus pertain to link speed
> changes at an upstream-facing port.

Got it, i will device's PCIe type,

> 
> Thanks,
> 
> Lukas

Thanks for valuable comments.

Best Regards,
Shuai