Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp162355imu; Wed, 21 Nov 2018 17:19:34 -0800 (PST) X-Google-Smtp-Source: AFSGD/XujYMiFXENe4rd9Uuno3eSnxfnE5mFGPfn+P04nwkUQe6tSub+qeexRk88I3+EYsPeVgn1 X-Received: by 2002:a17:902:e201:: with SMTP id ce1-v6mr9207289plb.138.1542849574281; Wed, 21 Nov 2018 17:19:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542849574; cv=none; d=google.com; s=arc-20160816; b=s7z2FsQBtBcWyvTl5VAVwgxP3S3v5DovHVW8xucKlYhRg/chTC4wExWGWwk4fEk7gi 2msEep75acI8JmrSWpa7Hm7YSyDDO/ZYFLJictZExCgUCCuEqMRqsueyqAXtGQq/hR4v nDnmVyD5N9suH/7ATcfni8iE9WN8CYVnYT14IOAYVKHyyg8RwAGrZHD+vzkwxu8tIhPF KK+x9Bs6xaaMi3ptI0FToSvbZRISV6T5tr4Td6fA7zot0nl079iholfaN9DannCcibXl /E2cLVqZJyL8j4DtQaQUYIgyeCc7mcfq0kWDN0c8h3v6P1s4bhTL5aFFyay+XMUjabeH u+6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=NbRhh58WlkIx5Z7b9xb1WqYhWeG+iUHeHnPNQtq3Pp0=; b=W9ufgfC5e+na8J8o2DetRq34ESuQmebUld0Y1yiHutVFHMlF3b0R/jn2L5/HBE4IUS NJQJBwE/at0cPQXOMoIcT0m8Aky3U2tQU3w7VsuPAERWsDTNkbSqTSr0wm9PL60HjPzC vvdopxZ36ppYWbpbGzLgfCBuIPHQRi2Koy3yo++clTlePXf0VEATwymKQssA54VF6rqj mi+Mj3fEiGiJ5kxTnsQ/u/OWKKPCVh8ghXEEgGzPtN/U6cH4s8qaA+Qi99V4lN1Cm34/ Rj1RB1/XglCgT78oxtU1i1WWmOTJAxdbCxFQNwLeUUr8OTNeUVsFnp/zZXxt08yq4gr2 QuoQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ows8ndOM; 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 f65si5255782pfb.194.2018.11.21.17.19.19; Wed, 21 Nov 2018 17:19:34 -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=@kernel.org header.s=default header.b=ows8ndOM; 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 S2388393AbeKVFp5 (ORCPT + 99 others); Thu, 22 Nov 2018 00:45:57 -0500 Received: from mail.kernel.org ([198.145.29.99]:40996 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727253AbeKVFp5 (ORCPT ); Thu, 22 Nov 2018 00:45:57 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3BA26206BB; Wed, 21 Nov 2018 19:10:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1542827423; bh=8JOTH2aLHViBIXw5/0s2i86YQ/3Iz238JPxDc0AfPzU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ows8ndOMZCjkSprYjM1zgdwpv28GLeiHQKOdQPmBqDLjgOhdD0/W4VSKs6e5KuJCL GLwXt6cXGOJ3YssjMvZSNk3fs/Xj2hWyt4ti05v1416Go46XTRIlSiXPtpLOopE+dH 3CVbDGAtWelIlmapj4ZJQe5rFSC8OgGmrfYpNfCU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Matthias Kaehlcke , Ingo Molnar , Masahiro Yamada , Nick Desaulniers Subject: [PATCH 4.9 24/59] x86/build: Specify stack alignment for clang Date: Wed, 21 Nov 2018 20:06:39 +0100 Message-Id: <20181121183509.210549454@linuxfoundation.org> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20181121183508.262873520@linuxfoundation.org> References: <20181121183508.262873520@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Matthias Kaehlcke commit d77698df39a512911586834d303275ea5fda74d0 upstream. For gcc stack alignment is configured with -mpreferred-stack-boundary=N, clang has the option -mstack-alignment=N for that purpose. Use the same alignment as with gcc. If the alignment is not specified clang assumes an alignment of 16 bytes, as required by the standard ABI. However as mentioned in d9b0cde91c60 ("x86-64, gcc: Use -mpreferred-stack-boundary=3 if supported") the standard kernel entry on x86-64 leaves the stack on an 8-byte boundary, as a consequence clang will keep the stack misaligned. Signed-off-by: Matthias Kaehlcke Acked-by: Ingo Molnar Signed-off-by: Masahiro Yamada Signed-off-by: Nick Desaulniers Signed-off-by: Greg Kroah-Hartman --- arch/x86/Makefile | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -11,6 +11,14 @@ else KBUILD_DEFCONFIG := $(ARCH)_defconfig endif +# For gcc stack alignment is specified with -mpreferred-stack-boundary, +# clang has the option -mstack-alignment for that purpose. +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),) + cc_stack_align_opt := -mpreferred-stack-boundary +else ifneq ($(call cc-option, -mstack-alignment=4),) + cc_stack_align_opt := -mstack-alignment +endif + # How to compile the 16-bit code. Note we always compile for -march=i386; # that way we can complain to the user if the CPU is insufficient. # @@ -28,7 +36,7 @@ REALMODE_CFLAGS := $(M16_CFLAGS) -g -Os REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -ffreestanding) REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -fno-stack-protector) -REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -mpreferred-stack-boundary=2) +REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), $(cc_stack_align_opt)=2) export REALMODE_CFLAGS # BITS is used as extension for files which are available in a 32 bit @@ -65,8 +73,10 @@ ifeq ($(CONFIG_X86_32),y) # with nonstandard options KBUILD_CFLAGS += -fno-pic - # prevent gcc from keeping the stack 16 byte aligned - KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=2) + # Align the stack to the register width instead of using the default + # alignment of 16 bytes. This reduces stack usage and the number of + # alignment instructions. + KBUILD_CFLAGS += $(call cc-option,$(cc_stack_align_opt)=2) # Disable unit-at-a-time mode on pre-gcc-4.0 compilers, it makes gcc use # a lot more stack due to the lack of sharing of stacklots: @@ -98,8 +108,14 @@ else KBUILD_CFLAGS += $(call cc-option,-mno-80387) KBUILD_CFLAGS += $(call cc-option,-mno-fp-ret-in-387) - # Use -mpreferred-stack-boundary=3 if supported. - KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=3) + # By default gcc and clang use a stack alignment of 16 bytes for x86. + # However the standard kernel entry on x86-64 leaves the stack on an + # 8-byte boundary. If the compiler isn't informed about the actual + # alignment it will generate extra alignment instructions for the + # default alignment which keep the stack *mis*aligned. + # Furthermore an alignment to the register width reduces stack usage + # and the number of alignment instructions. + KBUILD_CFLAGS += $(call cc-option,$(cc_stack_align_opt)=3) # Use -mskip-rax-setup if supported. KBUILD_CFLAGS += $(call cc-option,-mskip-rax-setup)