Received: by 10.223.176.5 with SMTP id f5csp1206584wra; Tue, 6 Feb 2018 14:49:52 -0800 (PST) X-Google-Smtp-Source: AH8x226Q+aMrbJP3DdelILH5tEu4RSzNcoa70qMqAe7fItXSIy1vqXaZxkcp157ZaznIWKri3Zdi X-Received: by 10.98.72.19 with SMTP id v19mr3914455pfa.107.1517957391939; Tue, 06 Feb 2018 14:49:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517957391; cv=none; d=google.com; s=arc-20160816; b=ws1P6KqyDOgfqVR1FY29cawDjOn5vvFiePiD4X14UBwEUMaRK94IfV4XMF7hinNS0M g0kAeBiR2s1hsFh9czwJ4mD/QUb4teJJOmEYu3aqXS1DWR36Y0YFPRZztc/IxS+tLF/9 91TB0QRP/GaFc37cpLS/qmoMUy3u9RofMmp0brjAUyOySYRCLhJFhECF4+5X5o3B1NW+ +XPIyDz41bzeWwgFVJ484XSm1ai1jbVerNNLhI2z3Crlb3MTm3ImetXhV4a5palJq6MB N9NsZ+YrFdY+bPlFeBvmthQbhGsbN1UrS8HMGWw5Sq+rTUfDrKWMGLM03ZuL/3j0C3Cy 7naA== 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:dkim-signature:arc-authentication-results; bh=kj4gruxTcwEzQcZ4OkDZjboWslHQyU+jq//Oh3wCf8Y=; b=kzEP3GLsTCU+q9L6Q9Dxc2zvP8bDPLtG2C98qnZRq24JgYvArV9rIw69qrUqJeYKmR mzjdYn5jQzZVtzWVCkjjoVNHNmxAayclazYuBtmH9lgyx1tf0WZKnWLly4VqaONc3m3C gMHnSsPi5fmoGTqr67XfuU1uN6OlnsWCCr/tzznWnDADWbMvA2J2toQv0uzzojvdPZTW sZd6BFIVTn0eIALMV20az6MADW8dSP0GHA4DSPE8imwcnAk9Luah2oUyrCGXzJqKK7In kAy0bR77t8gP9XQKyQPI9Asr/FgZK3d7UGrmvDwm5rsc9L10IbQsuANtL/LlH3yr5pl8 dWnA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=NrJC1naj; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d23si42903pgn.737.2018.02.06.14.49.37; Tue, 06 Feb 2018 14:49:51 -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; dkim=pass header.i=@chromium.org header.s=google header.b=NrJC1naj; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753704AbeBFWsv (ORCPT + 99 others); Tue, 6 Feb 2018 17:48:51 -0500 Received: from mail-pf0-f195.google.com ([209.85.192.195]:41711 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753673AbeBFWsr (ORCPT ); Tue, 6 Feb 2018 17:48:47 -0500 Received: by mail-pf0-f195.google.com with SMTP id 68so1284620pfj.8 for ; Tue, 06 Feb 2018 14:48:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=kj4gruxTcwEzQcZ4OkDZjboWslHQyU+jq//Oh3wCf8Y=; b=NrJC1najZ2lqOWbaPNl9BsPA6Nz1gZp38upJ13ji/zCIinQxcmZcI135RT7lDTMlK4 hK3FCKkkHFSLE7Zn5wKU9Nqg8+9c3/JqOchE7dFvxhQbyKn2go/bM5qusB/hP+0oXCtY 0dLzQrVmD9jNIZ/JJdV8qk7HsKYIrxQVTWUfc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=kj4gruxTcwEzQcZ4OkDZjboWslHQyU+jq//Oh3wCf8Y=; b=dfwdbN6AsDUal8M1Vn8IVWzT8JB3MQiVr1steXH74U76FumBrmwvknsWNNL4W9bvLZ X43Hov2efTyovpBRTO0ukTim4BimpPiPZXs3kE2WGQGNN5WU2NUm/RkzzfoFMsmbM328 CDMc8AUMFhyhrIcoHoKRmF9Sow5Xi/ai6jtLlFKlw6kE75xr1CDOC3qlxH6SFiEDle5w ScaEfPl0nJgF5GeSvO11MXDCHNw7pW8gCSj2ozRCM1v/AW79nvlkwT3/9F8p9rASqpqo ny8hBd3aK9nYFa7+FAvJf0oBL0BlRA9qfNB1cZkjJqB+H/7iIKUOjVaUMsCKNxRVDGRe Jy6A== X-Gm-Message-State: APf1xPC5V8hmZpfZCggRQtNvZfV41F5Brgi7tOLnvINxcw9awBgdD1jC uSZHsXPdDWcHLg76lfl1iiRLVQ== X-Received: by 10.98.185.14 with SMTP id z14mr3855310pfe.185.1517957326872; Tue, 06 Feb 2018 14:48:46 -0800 (PST) Received: from localhost ([2620:0:1000:1600:5ff4:666d:2881:a60]) by smtp.gmail.com with ESMTPSA id e82sm117530pfh.53.2018.02.06.14.48.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 06 Feb 2018 14:48:46 -0800 (PST) Date: Tue, 6 Feb 2018 14:48:45 -0800 From: Matthias Kaehlcke To: Greg Kroah-Hartman 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: <20180206224845.GA116483@google.com> References: <20180122083910.299610926@linuxfoundation.org> <20180122083910.527513802@linuxfoundation.org> <20180206215941.GA99249@google.com> <20180206223706.GC23990@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180206223706.GC23990@kroah.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org El Tue, Feb 06, 2018 at 02:37:06PM -0800 Greg Kroah-Hartman ha dit: > 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. Indeed, only the #ifndef change is needed. Thanks! m.