Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751362AbeAEKlB (ORCPT + 1 other); Fri, 5 Jan 2018 05:41:01 -0500 Received: from mail-it0-f68.google.com ([209.85.214.68]:38998 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751002AbeAEKlA (ORCPT ); Fri, 5 Jan 2018 05:41:00 -0500 X-Google-Smtp-Source: ACJfBotobg2TdeKoSr11nLtOOD5lUIWjVAAzXM211gYgztgXiN26q/jECNy4rAVuZ73Kwmt41dHiGg== Date: Fri, 5 Jan 2018 02:40:55 -0800 From: Paul Turner To: Linus Torvalds Cc: Alexei Starovoitov , David Woodhouse , Andi Kleen , LKML , Greg Kroah-Hartman , Tim Chen , Dave Hansen , Thomas Gleixner , Kees Cook , Rik van Riel , Peter Zijlstra , Andy Lutomirski , Jiri Kosina , One Thousand Gnomes Subject: Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support Message-ID: <20180105104055.GA253582@google.com> References: <1515058213.12987.89.camel@amazon.co.uk> <20180104143710.8961-1-dwmw@amazon.co.uk> <20180104181744.komdplek7nfdvlsw@ast-mbp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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:25:35AM -0800, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 10:17 AM, Alexei Starovoitov > wrote: > > > > Clearly Paul's approach to retpoline without lfence is faster. Using pause rather than lfence does not represent a fundamental difference here. A protected indirect branch is always adding ~25-30 cycles of overhead. That this can be avoided in practice is a function of two key factors: (1) Kernel code uses fewer indirect branches. (2) The overhead can be avoided for hot indirect branches via devirtualization. e.g. the semantic equivalent of, if (ptr == foo) foo(); else (*ptr)(); Allowing foo() to be called directly, even though it was provided as an indirect. > > 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 ? > > What is the alternative approach? Is it literally just doing a > > call 1f > 1: mov real_target,(%rsp) > ret > > on the assumption that the "ret" will always just predict to that "1" > due to the call stack? > > Linus