linux-kernel - Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

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: <1507972420.25065.270.camel@kernel.crashing.org>
Date:   Sat, 14 Oct 2017 11:13:40 +0200
From:   Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:     Michael Ellerman <mpe@...erman.id.au>,
        "Guilherme G. Piccoli" <gpiccoli@...ux.vnet.ibm.com>,
        linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Cc:     paulus@...ba.org, maurosr@...ux.vnet.ibm.com
Subject: Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to
 issue a PHB reset

On Fri, 2017-10-13 at 19:37 +1100, Michael Ellerman wrote:
> > We recently had a situation in which i40e driver couldn't start,
> > even after a full power cycle, due to a bug in its FW triggered
> > by a DCB condition in switch (thanks Mauro for narrowing this).
> > This patch enabled us to revive the adapter and use network
> > while debugging.
> 
> I really dislike this.
> 
> You're basically saying the kernel can't work out how to get a device
> working, so let's leave it up to the user.
> 
> The driver should be fixed to detect that the device is not responding
> and request a reset.

No, he's saying this is useful for the developers when debugging the
kernel driver (or for asking users to "test" something as part of
debugging a driver problem).

It's common to have various command line options affecting PCIe
behaviour. I don't see a fundamental problem with this one.

One could argue in fact that we should always PERST everything, the
main reason for not doing so is that on "normal" boot, OPAL has already
done it and it would slow the boot process down.

My only objection here is the actual name of the argument. We've had a
number of pci options so far, it makes sense to make sure we still have
"pci" in the name.

Also having the driver do a "reset" is not always simple, we don't
always have full control of PERST on a per-device basis. The patch
proposed will PERST top level PHBs which will propagate as hot reset
down switches, not 100% PERST but still useful.

Cheers,
Ben.