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: <20250717235055.GA2664149@bhelgaas>
Date: Thu, 17 Jul 2025 18:50:55 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Matthew W Carlis <mattc@...estorage.com>
Cc: lukas@...ner.de, anil.s.keshavamurthy@...el.com, bhelgaas@...gle.com,
	bp@...en8.de, davem@...emloft.net, ilpo.jarvinen@...ux.intel.com,
	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,
	xueshuai@...ux.alibaba.com
Subject: Re: [PATCH v8] PCI: hotplug: Add a generic RAS tracepoint for
 hotplug event

On Thu, Jul 17, 2025 at 05:27:58PM -0600, Matthew W Carlis wrote:
> On Thu, 17 Jul 2025, Bjorn Helgaas wrote:
> > - slot_name() (which I think comes from make_slot_name(); would you
> >   want something else?)
> 
> afaik it ends up coming from the Slot Cap Register "Physical Slot
> Number" bits.  I brought up the slot to just say that I was happy to
> see it & that it is useful for our purposes & why.

I don't think slot_name() is directly from Physical Slot Number
because there's nothing to guarantee that is unique.  I think
make_slot_name() starts with PSN but does add things to make sure the
name unique.

> On Thu, 17 Jul 2025, Lukas Wunner wrote:
> >> and IIUC, it would be helpful for you to add:
> ...

> >>   - USP/EP Vendor/Device ID
> >
> > There's no 1:1 relation between link or presence events on the one
> > hand, and enumeration of hotplugged components on the other hand:
> > The link may go up but the kernel may fail to enumerate the
> > component, e.g. because it was yanked before it could be
> > enumerated, or because the kernel has run out of MMIO space or bus
> > numbers.
> > 
> > Hence this would have to be logged through a separate tracepoint
> > in pciehp_configure_device(), not by changing the tracepoints
> > added here.

> Ok I think its reasonable to use a separate tracepoint that would have more
> information about the EP.

So I think your idea of adding current link speed/width to the "Link
Up" event is still on the table, and that does sound useful to me.

In the future we might add another tracepoint when we enumerate the
device and know the Vendor/Device ID.

Bjorn