Message ID | 20240127093728.1323-2-xin3.li@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-41150-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2395:b0:106:343:edcb with SMTP id gw21csp408990dyb; Sat, 27 Jan 2024 02:09:31 -0800 (PST) X-Google-Smtp-Source: AGHT+IEafE+xVNubUFjgVqxp1FTi6MEYV21WDIk8qS3Zo41ErL5jCdGTK3f/WYsBdhgQw/0K5jRQ X-Received: by 2002:a05:6402:2296:b0:55d:3735:ee06 with SMTP id cw22-20020a056402229600b0055d3735ee06mr762382edb.15.1706350171222; Sat, 27 Jan 2024 02:09:31 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706350171; cv=pass; d=google.com; s=arc-20160816; b=dYjP18pFk4zAIWzsIpyn1KLkLV/7IlhczDsFxBHJoztritGl8JtTvf8xImyTTgTWxN t57rvhl+ckV7ZWLwDcWn7SJhd0GAdfmtRYnj+J6KJsVRWNKiLzjaYu/y6PyTwcgllgau nofCZVFBrOGxNzkLu2W4Sc8eSmAiEE9tlcrq1uKkTtNAQ9rQdCJzZ1ZZY2CZvKrCf5JE wAVtEunaNp4CUs4QFUGrJdnVOKlyLSGN+epeQ33d544QIBIgLHw+q+2qLrFkYlCK7vCY MXU4LRhl/BYXgpnIhynAZeFmivG6WfuesSjuoiC9CSR4NDS/3BPJ6ujOAjW72Ia4KJcf i/AA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=/OH4QgJDAHM+A72EaK5W5GmONMy6pfOViQ0QJYfujFM=; fh=eoqNldmLmBswfN1zMWVVrnsIvNovukkqS6g9u7sxTHc=; b=ZThqBZ3FiTqpWAIioCATgFh0irK4iQr/G7oKG11wobW38iWXBxp5lnoQWaDN1Cx+rg tbOxE0b4n3Yq1QzEtfFXj6UL6b3Pt4KAM2U29P8ld5DfrEDTTWRQKV1vCl8HnhZYFs1v x13R2lznOHiQKc+IOK5z/9wbr8Ljb/fELmP48OyEzJHTQXiPxWR0JH4mpPEVlMLLXlXY Y2ARrcQxACA1ZitdRFrYY2NiCcZckj0lwTn2QrMuTrIiAq43BzztX0sDfejFOqcX2a04 ecPMERV+EjvnnntTbmfWxcJ8yIe13yM/e/oGtYf+xiu3pawXqK994IzfNwX6RCYcuEJh rIDg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="ljV/bZI+"; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-41150-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-41150-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id dj11-20020a05640231ab00b00559675992b4si1555609edb.593.2024.01.27.02.09.31 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Jan 2024 02:09:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-41150-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="ljV/bZI+"; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-41150-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-41150-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id D3ED31F2378B for <ouuuleilei@gmail.com>; Sat, 27 Jan 2024 10:09:30 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4744820DE6; Sat, 27 Jan 2024 10:08:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ljV/bZI+" Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 45FB21E88B for <linux-kernel@vger.kernel.org>; Sat, 27 Jan 2024 10:08:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.8 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706350136; cv=none; b=rR+FpxSxl3d3P0wFkkCVWuAUb71ZV0vHdqT4DSsR6ZJfwyToPtF7hBYQ7yElrWzsOnXKBdPPp0TwihMVBBBj96XbMVlc70O1QFmQwhjx4ELoDFP6PayNS8YGT4MNExqrHIiRH6zjowTtrj//W4i2LEjuuNS8pJulVM+EBgxKuK0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706350136; c=relaxed/simple; bh=bXMF274IqJ6MOt+D70wBFlrfZWyDlvVU+rh4CQrcsg4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=h8XBnNPHIbyTa4PfgkWyoK2EqhCLcEcLvT4M570bsXYO7pf+bCWOwmaqPozUrEcd5Ty5HIVs1ZJRWCswrPTt/riiX0zTopWwm8MJwFVJlDIXc+4Mg+XQk3jdcSXptrqZxIyDjOiDtBy+YT8drNDyEppCMcWhug58vrfy3+jVEbM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ljV/bZI+; arc=none smtp.client-ip=192.198.163.8 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1706350135; x=1737886135; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=bXMF274IqJ6MOt+D70wBFlrfZWyDlvVU+rh4CQrcsg4=; b=ljV/bZI+nKVnuetBKnR86yb5MNFco/1g/FuK7am+SWHd5QsmSr/qXTZI 2Rr74VfJKmX+4QfDpsuG1ZTBsPI4v3rcY1I7aocjT/CXQKEep0T1xZe3m 8iOLaTQ8xxmVHb7SkZOm11wdcVPTk7NKggsVOAp6PmaKG/YUMhroLHjw0 X+BBpbUHlkhc7JMWMDCMQ1CqWjRU4yuMsi+Ubdo2BST2KhN5rXw7f9RAJ wsCrxX67TdWqRYBXafGDDmxJ6/QhOWdafgNwM9NCt2qwJUwyEKBzTOB9U g6K0VQVZoOi2+Kqv3b8pduuDiCYH98BCwkUFQsY70cqVQ0tQt0SZQIjdw Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10964"; a="16190972" X-IronPort-AV: E=Sophos;i="6.05,220,1701158400"; d="scan'208";a="16190972" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2024 02:08:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10964"; a="736923489" X-IronPort-AV: E=Sophos;i="6.05,220,1701158400"; d="scan'208";a="736923489" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga003.jf.intel.com with ESMTP; 27 Jan 2024 02:08:51 -0800 From: Xin Li <xin3.li@intel.com> To: linux-kernel@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, ravi.v.shankar@intel.com, andrew.cooper3@citrix.com Subject: [PATCH 1/2] x86/fred: Fix build with clang Date: Sat, 27 Jan 2024 01:37:27 -0800 Message-ID: <20240127093728.1323-2-xin3.li@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240127093728.1323-1-xin3.li@intel.com> References: <20240127093728.1323-1-xin3.li@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789237837165267970 X-GMAIL-MSGID: 1789237837165267970 |
Series |
x86/fred: Fix two build issues
|
|
Commit Message
Li, Xin3
Jan. 27, 2024, 9:37 a.m. UTC
As clang doesn't allow .fill to refernece a symbol before it's defined,
use asm_fred_entrypoint_user instead of asm_fred_entrypoint_kernel.
Fixes: 5e0636a41485 ("x86/fred: FRED entry/exit and dispatch code")
Reported-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/lkml/20240126100050.GAZbOC0g3Rlr6otZcT@fat_crate.local/
Signed-off-by: Xin Li <xin3.li@intel.com>
---
arch/x86/entry/entry_64_fred.S | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Comments
On January 27, 2024 1:37:27 AM PST, Xin Li <xin3.li@intel.com> wrote: >As clang doesn't allow .fill to refernece a symbol before it's defined, >use asm_fred_entrypoint_user instead of asm_fred_entrypoint_kernel. > >Fixes: 5e0636a41485 ("x86/fred: FRED entry/exit and dispatch code") >Reported-by: Borislav Petkov (AMD) <bp@alien8.de> >Link: https://lore.kernel.org/lkml/20240126100050.GAZbOC0g3Rlr6otZcT@fat_crate.local/ >Signed-off-by: Xin Li <xin3.li@intel.com> >--- > arch/x86/entry/entry_64_fred.S | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > >diff --git a/arch/x86/entry/entry_64_fred.S b/arch/x86/entry/entry_64_fred.S >index eedf98de7538..5427e0da190d 100644 >--- a/arch/x86/entry/entry_64_fred.S >+++ b/arch/x86/entry/entry_64_fred.S >@@ -43,13 +43,12 @@ SYM_INNER_LABEL(asm_fred_exit_user, SYM_L_GLOBAL) > _ASM_EXTABLE_TYPE(1b, asm_fred_entrypoint_user, EX_TYPE_ERETU) > SYM_CODE_END(asm_fred_entrypoint_user) > >-.fill asm_fred_entrypoint_kernel - ., 1, 0xcc >- > /* > * The new RIP value that FRED event delivery establishes is > * (IA32_FRED_CONFIG & ~FFFH) + 256 for events that occur in > * ring 0, i.e., asm_fred_entrypoint_user + 256. > */ >+ .fill asm_fred_entrypoint_user + 256 - ., 1, 0xcc > .org asm_fred_entrypoint_user + 256 > SYM_CODE_START_NOALIGN(asm_fred_entrypoint_kernel) > FRED_ENTER .fill and .org here are redundant; in fact, there two directives mean exactly the same thing except that .org implicitly subtracts the current offset.
> >diff --git a/arch/x86/entry/entry_64_fred.S > >b/arch/x86/entry/entry_64_fred.S index eedf98de7538..5427e0da190d > >100644 > >--- a/arch/x86/entry/entry_64_fred.S > >+++ b/arch/x86/entry/entry_64_fred.S > >@@ -43,13 +43,12 @@ SYM_INNER_LABEL(asm_fred_exit_user, > SYM_L_GLOBAL) > > _ASM_EXTABLE_TYPE(1b, asm_fred_entrypoint_user, EX_TYPE_ERETU) > > SYM_CODE_END(asm_fred_entrypoint_user) > > > >-.fill asm_fred_entrypoint_kernel - ., 1, 0xcc > >- > > /* > > * The new RIP value that FRED event delivery establishes is > > * (IA32_FRED_CONFIG & ~FFFH) + 256 for events that occur in > > * ring 0, i.e., asm_fred_entrypoint_user + 256. > > */ > >+ .fill asm_fred_entrypoint_user + 256 - ., 1, 0xcc > > .org asm_fred_entrypoint_user + 256 > > SYM_CODE_START_NOALIGN(asm_fred_entrypoint_kernel) > > FRED_ENTER > > .fill and .org here are redundant; in fact, there two directives mean exactly the > same thing except that .org implicitly subtracts the current offset. Ah, right, .fill already does the job! I will remove .org.
On 1/27/24 11:46, Li, Xin3 wrote: >>> diff --git a/arch/x86/entry/entry_64_fred.S >>> b/arch/x86/entry/entry_64_fred.S index eedf98de7538..5427e0da190d >>> 100644 >>> --- a/arch/x86/entry/entry_64_fred.S >>> +++ b/arch/x86/entry/entry_64_fred.S >>> @@ -43,13 +43,12 @@ SYM_INNER_LABEL(asm_fred_exit_user, >> SYM_L_GLOBAL) >>> _ASM_EXTABLE_TYPE(1b, asm_fred_entrypoint_user, EX_TYPE_ERETU) >>> SYM_CODE_END(asm_fred_entrypoint_user) >>> >>> -.fill asm_fred_entrypoint_kernel - ., 1, 0xcc >>> - >>> /* >>> * The new RIP value that FRED event delivery establishes is >>> * (IA32_FRED_CONFIG & ~FFFH) + 256 for events that occur in >>> * ring 0, i.e., asm_fred_entrypoint_user + 256. >>> */ >>> + .fill asm_fred_entrypoint_user + 256 - ., 1, 0xcc >>> .org asm_fred_entrypoint_user + 256 >>> SYM_CODE_START_NOALIGN(asm_fred_entrypoint_kernel) >>> FRED_ENTER >> >> .fill and .org here are redundant; in fact, there two directives mean exactly the >> same thing except that .org implicitly subtracts the current offset. > > Ah, right, .fill already does the job! > > I will remove .org. > Incidentally, was there a problem with .org ..., 0xcc? Not a criticism, I just want to know to better understand current binutils limitations. -hpa
> >>> @@ -43,13 +43,12 @@ SYM_INNER_LABEL(asm_fred_exit_user, > >> SYM_L_GLOBAL) > >>> _ASM_EXTABLE_TYPE(1b, asm_fred_entrypoint_user, EX_TYPE_ERETU) > >>> SYM_CODE_END(asm_fred_entrypoint_user) > >>> > >>> -.fill asm_fred_entrypoint_kernel - ., 1, 0xcc > >>> - > >>> /* > >>> * The new RIP value that FRED event delivery establishes is > >>> * (IA32_FRED_CONFIG & ~FFFH) + 256 for events that occur in > >>> * ring 0, i.e., asm_fred_entrypoint_user + 256. > >>> */ > >>> + .fill asm_fred_entrypoint_user + 256 - ., 1, 0xcc > >>> .org asm_fred_entrypoint_user + 256 > >>> SYM_CODE_START_NOALIGN(asm_fred_entrypoint_kernel) > >>> FRED_ENTER > >> > >> .fill and .org here are redundant; in fact, there two directives mean > >> exactly the same thing except that .org implicitly subtracts the current offset. > > > > Ah, right, .fill already does the job! > > > > I will remove .org. > > > > Incidentally, was there a problem with .org ..., 0xcc? Oh, it's just that I didn't know .org can be used to fill. > Not a criticism, I just want to know to better understand current binutils > limitations. > > -hpa
diff --git a/arch/x86/entry/entry_64_fred.S b/arch/x86/entry/entry_64_fred.S index eedf98de7538..5427e0da190d 100644 --- a/arch/x86/entry/entry_64_fred.S +++ b/arch/x86/entry/entry_64_fred.S @@ -43,13 +43,12 @@ SYM_INNER_LABEL(asm_fred_exit_user, SYM_L_GLOBAL) _ASM_EXTABLE_TYPE(1b, asm_fred_entrypoint_user, EX_TYPE_ERETU) SYM_CODE_END(asm_fred_entrypoint_user) -.fill asm_fred_entrypoint_kernel - ., 1, 0xcc - /* * The new RIP value that FRED event delivery establishes is * (IA32_FRED_CONFIG & ~FFFH) + 256 for events that occur in * ring 0, i.e., asm_fred_entrypoint_user + 256. */ + .fill asm_fred_entrypoint_user + 256 - ., 1, 0xcc .org asm_fred_entrypoint_user + 256 SYM_CODE_START_NOALIGN(asm_fred_entrypoint_kernel) FRED_ENTER