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]
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ