From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751782AbeAEKc4 (ORCPT + 1 other); Fri, 5 Jan 2018 05:32:56 -0500 Received: from mail-pg0-f65.google.com ([74.125.83.65]:41536 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751742AbeAEKcx (ORCPT ); Fri, 5 Jan 2018 05:32:53 -0500 X-Google-Smtp-Source: ACJfBouiguF9KcaOqc5cAvPMk20qh62itQs63dyP2DWXDu16UG/Z82AiX+Thmt2VK8rcAGkO43LfDg== Date: Fri, 5 Jan 2018 02:32:49 -0800 From: Paul Turner To: Andi Kleen Cc: Alexei Starovoitov , David Woodhouse , LKML , Linus Torvalds , Greg Kroah-Hartman , Tim Chen , Dave Hansen , tglx@linutronix.de, Kees Cook , Rik van Riel , Peter Zijlstra , Andy Lutomirski , Jiri Kosina , gnomes@lxorguk.ukuu.org.uk Subject: Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support Message-ID: <20180105103249.GB247671@google.com> References: <1515058213.12987.89.camel@amazon.co.uk> <20180104143710.8961-1-dwmw@amazon.co.uk> <20180104181744.komdplek7nfdvlsw@ast-mbp> <20180104184023.GB25714@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180104184023.GB25714@tassilo.jf.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, Jan 04, 2018 at 10:40:23AM -0800, Andi Kleen wrote: > > Clearly Paul's approach to retpoline without lfence is faster. > > I'm guessing it wasn't shared with amazon/intel until now and > > this set of patches going to adopt it, right? > > > > Paul, could you share a link to a set of alternative gcc patches > > that do retpoline similar to llvm diff ? > > I don't think it's a good idea to use any sequence not signed > off by CPU designers and extensively tested. I can confirm that "pause; jmp" has been previously reviewed by your side. That said, again, per the other email, once we have guaranteed that speculative execution will reach this point, beyond the guarantee that it does something "safe" the choice of sequence here is a performance detail rather than correctness. > > While another one may work for most tests, it could always fail in > some corner case. > > Right now we have the more heavy weight one and I would > suggest to stay with that one for now. Then worry > about more optimizations later. > > Correctness first. > > -Andi