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:   Tue, 29 May 2018 09:40:09 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Fenghua Yu <fenghua.yu@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...e.hu>,
        "H. Peter Anvin" <hpa@...ux.intel.com>
Cc:     Ashok Raj <ashok.raj@...el.com>,
        Rafael Wysocki <rafael.j.wysocki@...el.com>,
        Tony Luck <tony.luck@...el.com>,
        Alan Cox <alan@...ux.intel.com>,
        Ravi V Shankar <ravi.v.shankar@...el.com>,
        Arjan van de Ven <arjan@...radead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [RFC PATCH 00/16] x86/split_lock: Enable #AC exception for split
 locked accesses

On 05/27/2018 08:45 AM, Fenghua Yu wrote:
> A split lock is any atomic operation whose operand crosses two cache
> lines. Since the operand spans two cache lines and the operation must
> be atomic, the system locks the bus while the CPU accesses the two cache
> lines.

Could you give us a bit of an idea why this is RFC?  What needs review?
What needs commenting-on?  What is left before you think this can be
merged?  Where would you like Thomas, Ingo, and other reviewers to focus
their attention?

One thing we from Intel can be horrible about is launching in to the
details of the hardware implementation instead of focusing on the
software implications.  For instance, you launch into the details of bus
locks without mentioning key things like:

Split-lock-detection is a new hardware feature that generates
alignment-check (#AC) faults to help detect when badly-aligned atomic
instructions might impact whole-system performance.  These patches are
primarily targeted at application-level issues, but we can also detect
the same issues in the kernel.  There is a significant interaction
between this feature and firmware because firmware may or may not be
prepared for this feature to be enabled.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ