From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Williams Subject: Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok Date: Sat, 6 Jan 2018 10:54:27 -0800 Message-ID: References: <151520099201.32271.4677179499894422956.stgit@dwillia2-desk3.amr.corp.intel.com> <151520102670.32271.8447983009852138826.stgit@dwillia2-desk3.amr.corp.intel.com> <20180106123242.77f4d860@alans-desktop> <20180106181331.mmrqwwbu2jcjj2si@ast-mbp> <20180106183937.vkseldf4arkdlkum@ast-mbp> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20180106183937.vkseldf4arkdlkum@ast-mbp> Sender: netdev-owner@vger.kernel.org To: Alexei Starovoitov Cc: Alan Cox , Linus Torvalds , Linux Kernel Mailing List , linux-arch@vger.kernel.org, Andi Kleen , Arnd Bergmann , Greg Kroah-Hartman , Peter Zijlstra , Netdev , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner List-Id: linux-arch.vger.kernel.org On Sat, Jan 6, 2018 at 10:39 AM, Alexei Starovoitov wrote: [..] >> retpoline is variant-2, this patch series is about variant-1. > > that's exactly the point. Don't slow down the kernel with lfences > to solve variant 1. retpoline for 2 is ok from long term kernel > viability perspective. > Setting aside that we still need to measure the impact of these changes the end result will still be nospec_array_ptr() sprinkled in various locations. So can we save the debate about what's inside that macro on various architectures and at least proceed with annotating the problematic locations? Perhaps we can go a step further and have a config option to switch between the clever array_access() approach from Linus that might be fine depending on the compiler, and the cpu-vendor-recommended not to speculate implementation of nospec_array_ptr(). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f65.google.com ([209.85.218.65]:38450 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752674AbeAFSy2 (ORCPT ); Sat, 6 Jan 2018 13:54:28 -0500 Received: by mail-oi0-f65.google.com with SMTP id r65so5093081oie.5 for ; Sat, 06 Jan 2018 10:54:28 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20180106183937.vkseldf4arkdlkum@ast-mbp> References: <151520099201.32271.4677179499894422956.stgit@dwillia2-desk3.amr.corp.intel.com> <151520102670.32271.8447983009852138826.stgit@dwillia2-desk3.amr.corp.intel.com> <20180106123242.77f4d860@alans-desktop> <20180106181331.mmrqwwbu2jcjj2si@ast-mbp> <20180106183937.vkseldf4arkdlkum@ast-mbp> From: Dan Williams Date: Sat, 6 Jan 2018 10:54:27 -0800 Message-ID: Subject: Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok Content-Type: text/plain; charset="UTF-8" Sender: linux-arch-owner@vger.kernel.org List-ID: To: Alexei Starovoitov Cc: Alan Cox , Linus Torvalds , Linux Kernel Mailing List , linux-arch@vger.kernel.org, Andi Kleen , Arnd Bergmann , Greg Kroah-Hartman , Peter Zijlstra , Netdev , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner Message-ID: <20180106185427.51oImfx9wtBAJrwkhqLtlKbPS1HuieDQP9_muZ-du7g@z> On Sat, Jan 6, 2018 at 10:39 AM, Alexei Starovoitov wrote: [..] >> retpoline is variant-2, this patch series is about variant-1. > > that's exactly the point. Don't slow down the kernel with lfences > to solve variant 1. retpoline for 2 is ok from long term kernel > viability perspective. > Setting aside that we still need to measure the impact of these changes the end result will still be nospec_array_ptr() sprinkled in various locations. So can we save the debate about what's inside that macro on various architectures and at least proceed with annotating the problematic locations? Perhaps we can go a step further and have a config option to switch between the clever array_access() approach from Linus that might be fine depending on the compiler, and the cpu-vendor-recommended not to speculate implementation of nospec_array_ptr().