netdev - Re: PCI: Work around PCIe link training failures

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: <alpine.DEB.2.21.2407291540120.48387@angie.orcam.me.uk>
Date: Mon, 29 Jul 2024 15:51:37 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
cc: Matthew W Carlis <mattc@...estorage.com>, alex.williamson@...hat.com, 
    Bjorn Helgaas <bhelgaas@...gle.com>, christophe.leroy@...roup.eu, 
    "David S. Miller" <davem@...emloft.net>, david.abdurachmanov@...il.com, 
    edumazet@...gle.com, kuba@...nel.org, leon@...nel.org, 
    LKML <linux-kernel@...r.kernel.org>, linux-pci@...r.kernel.org, 
    linux-rdma@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org, 
    Lukas Wunner <lukas@...ner.de>, mahesh@...ux.ibm.com, 
    Mika Westerberg <mika.westerberg@...ux.intel.com>, mpe@...erman.id.au, 
    Netdev <netdev@...r.kernel.org>, npiggin@...il.com, oohall@...il.com, 
    pabeni@...hat.com, pali@...nel.org, saeedm@...dia.com, sr@...x.de, 
    Jim Wilson <wilson@...iptree.org>
Subject: Re: PCI: Work around PCIe link training failures

On Mon, 29 Jul 2024, Ilpo Järvinen wrote:

> > > The main reason is it is believed that it is the downstream device
> > > causing the issue, and obviously you can't fetch its ID if you can't
> > > negotiate link so as to talk to it in the first place.
> > 
> > Have had some more time to look into this issue. So, I think the problem
> > with this change is that it is quite strict in its assumptions about what
> > it means when a device fails to train, but in an environment where hot-plug
> > is exercised frequently you are essentially bound have something interrupt
> > the link training. In the first case where we caught this problem our test
> > automation was doing some power cycle tortures on our endpoints. If you catch
> > the right timing the link will be forced down to Gen1 forever without some other
> > automation to recover you unless your device is the one single device in the
> > allowlist which had the hardware bug in the first place.
> > 
> > I wonder if we can come up with some kind of alternative.
> 
> The most obvious solution is to not leave the speed at Gen1 on failure in 
> Target Speed quirk but to restore the original Target Speed value. The 
> downside with that is if the current retraining interface (function) is 
> used, it adds delay. But the retraining functions could be reworked such 
> that the retraining is only triggered in case the Target Speed quirk 
> fails but we don't wait for its result (which will very likely fail 
> anyway).

 This is what I have also been thinking of.

 After these many years it took from the inception of this change until it 
landed upstream I'm not sure anymore what my original idea was behind 
leaving the link clamped on a retrain failure, but I think it was either 
not to fiddle with the setting beyond the absolute necessity at hand 
(which the scenarios such as Matthew's prove wrong) or to leave the 
setting in a hope that training will eventually have succeeded (but it 
seems to make little sense as there'll be nothing there to actually 
observe the success unless the bus gets rescanned for another reason).

 I'll be at my lab towards the end of the week with a maintenance visit, 
so I'll allocate some time to fiddle with this issue on that occasion and 
implement such an update.

  Maciej