Received: by 10.223.176.5 with SMTP id f5csp1198007wra; Tue, 6 Feb 2018 14:38:09 -0800 (PST) X-Google-Smtp-Source: AH8x224si3XS4W8TSbPFX8ZMI/iSKSVxlU2SXTfhKxyhYGrLxsyXBDJDxe21PRVSPsvYsj/vF9Jy X-Received: by 10.98.245.87 with SMTP id n84mr3827388pfh.129.1517956689654; Tue, 06 Feb 2018 14:38:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517956689; cv=none; d=google.com; s=arc-20160816; b=rhrEpQvCCU+TZ9V+Y0dBahAP5LM/P9EhsrOApfsjWR3x/m0gYpB2xfyc6kRppf9XyH gomEfmv28Oe5H3Tll6EDgPbnnCvEEaxYVuNk8QukLr4W7e+GRVpaSKMfr29ysQdAjqNj 0qk4rkBYH9Ee2tAlb8hXIF2IWw30p/QWBZzvsY1j3owOrTv+hNlloisEJLTmObv5EcDK pG8wfhJ0oyrYj6tL+5XJN35da0VM3Z8LgVAFGPhJvtKan6h0GdU9tw2VDCItFZysbVD0 ynJ4VH8SnVlTrA7gPzOH+BLedmlWA4RwwQftf296ogIpUt6etTKVUxd9eFCawAFzpLzi tLQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=5y8kU+dRY+qeRVRv6qtCndQ4T7HpdeH7OgI22+9qOoY=; b=h1KmmZPtOvAwrNXBE1uYOuJRL5Uabm2o1fkz8xu8v8AL2gt1htkC7lWZjUaIpw8KlA YQjLDq+d+ZD5uHoN6P74kHdGZApkDdOn6s6ayygJO8da2rDF2kIcgmIyEJkXGs4vWql2 GAWhkj74dEoRJqoAqtbNdwSLdYg7WuF0FD/keF9ggifngAidqBB7/7J3Fj/J1lWW9dVp kbQxQOpnTJZGGnmI8X3zO79Xu0D8kQzBlRoUndEVnoE2YQs/nZJtZynH++GR4gInlSna b1NmFz7J2SV+dW6B0hX67lKncaHtTXzp2aR5QTT4u/N37O3W4aCnsbfIBY9z7MurF15S p3Tg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 93-v6si3351plc.515.2018.02.06.14.37.51; Tue, 06 Feb 2018 14:38:09 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753519AbeBFWhJ (ORCPT + 99 others); Tue, 6 Feb 2018 17:37:09 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:60042 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753235AbeBFWhI (ORCPT ); Tue, 6 Feb 2018 17:37:08 -0500 Received: from localhost (unknown [104.133.2.98]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 188AFFB8; Tue, 6 Feb 2018 22:37:08 +0000 (UTC) Date: Tue, 6 Feb 2018 14:37:06 -0800 From: Greg Kroah-Hartman To: Matthias Kaehlcke Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Andrey Ryabinin , Josh Poimboeuf , Andy Lutomirski , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , David Woodhouse , Razvan Ghitulete , Guenter Roeck , Nick Desaulniers , Greg Hackmann Subject: Re: [PATCH 4.4 05/53] x86/asm: Use register variable to get stack pointer value Message-ID: <20180206223706.GC23990@kroah.com> References: <20180122083910.299610926@linuxfoundation.org> <20180122083910.527513802@linuxfoundation.org> <20180206215941.GA99249@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180206215941.GA99249@google.com> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 06, 2018 at 01:59:41PM -0800, Matthias Kaehlcke wrote: > Hi Greg, > > El Mon, Jan 22, 2018 at 09:39:57AM +0100 Greg Kroah-Hartman ha dit: > > > 4.4-stable review patch. If anyone has any objections, please let me know. > > > > ------------------ > > > > From: Andrey Ryabinin > > > > commit 196bd485ee4f03ce4c690bfcf38138abfcd0a4bc upstream. > > > > Currently we use current_stack_pointer() function to get the value > > of the stack pointer register. Since commit: > > > > f5caf621ee35 ("x86/asm: Fix inline asm call constraints for Clang") > > > > ... we have a stack register variable declared. It can be used instead of > > current_stack_pointer() function which allows to optimize away some > > excessive "mov %rsp, %" instructions: > > > > -mov %rsp,%rdx > > -sub %rdx,%rax > > -cmp $0x3fff,%rax > > -ja ffffffff810722fd > > > > +sub %rsp,%rax > > +cmp $0x3fff,%rax > > +ja ffffffff810722fa > > > > Remove current_stack_pointer(), rename __asm_call_sp to current_stack_pointer > > and use it instead of the removed function. > > > > Signed-off-by: Andrey Ryabinin > > Reviewed-by: Josh Poimboeuf > > Cc: Andy Lutomirski > > Cc: Linus Torvalds > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Link: http://lkml.kernel.org/r/20170929141537.29167-1-aryabinin@virtuozzo.com > > Signed-off-by: Ingo Molnar > > [dwmw2: We want ASM_CALL_CONSTRAINT for retpoline] > > Signed-off-by: David Woodhouse > > Signed-off-by: Razvan Ghitulete > > Signed-off-by: Greg Kroah-Hartman > > We recently merged this patch to the Chrome OS kernel tree and it > broke our x86 builds with clang: > > arch/x86/include/asm/asm.h:116:50: error: register 'rsp' unsuitable for global register variables on this target > register unsigned long current_stack_pointer asm(_ASM_SP); > ^ > arch/x86/include/asm/asm.h:41:18: note: expanded from macro '_ASM_SP' > #define _ASM_SP __ASM_REG(sp) > ^ > arch/x86/include/asm/asm.h:24:32: note: expanded from macro '__ASM_REG' > #define __ASM_REG(reg) __ASM_SEL_RAW(e##reg, r##reg) > ^ > arch/x86/include/asm/asm.h:19:29: note: expanded from macro '__ASM_SEL_RAW' > # define __ASM_SEL_RAW(a,b) __ASM_FORM_RAW(b) > ^ > arch/x86/include/asm/asm.h:10:32: note: expanded from macro '__ASM_FORM_RAW' > # define __ASM_FORM_RAW(x) #x > ^ > :4:1: note: expanded from here > "rsp" > ^ > 1 error generated. > > > This can be fixed by also integrating the following patch: > > commit 520a13c530aeb5f63e011d668c42db1af19ed349 > Author: Josh Poimboeuf > Date: Thu Sep 28 16:58:26 2017 -0500 > > x86/asm: Fix inline asm call constraints for GCC 4.4 > > > Admittedly a v4.4 kernel built with clang + LTS merges is a very > special case and we can fix this in Chrome OS by integrating the above > patch locally. Still it would be good to get it into stable to avoid > others from running into this, especially since the fix is very > simple. > > Actually I just noticed that the patch also isn't in v4.9, which could > extend the number of affected 'users' significantly, so I think we > almost certainly want Josh's patch in stable. That patch doesn't apply cleanly to the 4.4.y or 4.9.y trees anymore. It seems that only one hunk of it is really needed, the #ifndef change, right? If so, I'll be glad to apply that portion. thanks, greg k-h