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: <20200629193316.GA3283437@bjorn-Precision-5520>
Date:   Mon, 29 Jun 2020 14:33:16 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Aya Levin <ayal@...lanox.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Saeed Mahameed <saeedm@...lanox.com>,
        "mkubecek@...e.cz" <mkubecek@...e.cz>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Tariq Toukan <tariqt@...lanox.com>, linux-pci@...r.kernel.org,
        Alexander Duyck <alexander.h.duyck@...ux.intel.com>,
        Ashok Raj <ashok.raj@...el.com>,
        Ding Tianhong <dingtianhong@...wei.com>,
        Casey Leedom <leedom@...lsio.com>
Subject: Re: [net-next 10/10] net/mlx5e: Add support for PCI relaxed ordering

[+cc Ashok, Ding, Casey]

On Mon, Jun 29, 2020 at 12:32:44PM +0300, Aya Levin wrote:
> I wanted to turn on RO on the ETH driver based on
> pcie_relaxed_ordering_enabled().
> From my experiments I see that pcie_relaxed_ordering_enabled() return true
> on Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz. This CPU is from Haswell
> series which is known to have bug in RO implementation. In this case, I
> expected pcie_relaxed_ordering_enabled() to return false, shouldn't it?

Is there an erratum for this?  How do we know this device has a bug
in relaxed ordering?

> In addition, we are worried about future bugs in new CPUs which may result
> in performance degradation while using RO, as long as the function
> pcie_relaxed_ordering_enabled() will return true for these CPUs. 

I'm worried about this too.  I do not want to add a Device ID to the
quirk_relaxedordering_disable() list for every new Intel CPU.  That's
a huge hassle and creates a real problem for old kernels running on
those new CPUs, because things might work "most of the time" but not
always.

Maybe we need to prevent the use of relaxed ordering for *all* Intel
CPUs.

> That's why
> we thought of adding the feature on our card with default off and enable the
> user to set it.

Bjorn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ