Received: by 2002:a25:2c96:0:0:0:0:0 with SMTP id s144csp1510634ybs; Mon, 25 May 2020 18:44:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwhQx14mYpWcuvjItaXW0t0xZou1n9QiFIlrNCq8I4HhYgUUOsxUilrB/tCJbqR75Gy/Lh0 X-Received: by 2002:a50:e711:: with SMTP id a17mr17922880edn.369.1590457489762; Mon, 25 May 2020 18:44:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590457489; cv=none; d=google.com; s=arc-20160816; b=R1RHG4K8dIxEWDx1ploVbK3UH71xzV5XGNUE51EqMjtbimVe1pu21ygPwuKoCcFVM1 i/0vb9p/W85VK0MLYjqQKwZEtWoG2oU9pZbFJvvDJRchP2ZgRLTz/DZ/zW6Q6xPJFbYJ 0Z5S2H7MEDhnHAmbCgAtJVS7KlGHkOY1W+nFXwtBX/06mPaCm9beSHm54N4JJ9n6UfEj GEMmxru0cVoTdXpvNkX6fx+kwq8IUvsCrwbGY90ASYSmHHq+mD2P6wko+pydQaQbEDlw A8d19YRa8XC4s+0ha4N/GifmgVsEj2CZjWRSiZSBVXYcliXReGt+q9d86VEeySiGI2Xf B9tQ== 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 :references:in-reply-to:message-id:date:subject:cc:to:from; bh=0wnThUqmuEUSyUlpySuSMQvYEdX6QHreeVNqxvepVR0=; b=oHoLxhRNq9OwY8jzpWIYheKSzFfRI26xrUK/Uo2NUiSHzpv8f0X+//83zytSqCLeP0 tbb5E134wSu3NrPQj66Zadd9S+Z+YtxDaO+zXIFJRlPFR2CCPAFmgYN57o0DgiexB6fm 35a+RNHwLXRdH0qSK5/52/Q3KiNB95TRngY4abPgiVy1grPWdgn+AzxuXhLLiirxGykD 5XMnYolp7wev0T5mM14Ib1VtPlCbwGyCiGkgGgBsvK/PpbDH6PqIqFwzbCvzcelcGpvD y3LzWaUuDDo+HGY13OX23/PukvZq8c+dXQ3ATVMIz/KVSsY9cxsjXHVet6EZiuH37r0q hWXA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s18si10450043ejh.293.2020.05.25.18.44.27; Mon, 25 May 2020 18:44:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388478AbgEZBmj (ORCPT + 99 others); Mon, 25 May 2020 21:42:39 -0400 Received: from out30-130.freemail.mail.aliyun.com ([115.124.30.130]:46947 "EHLO out30-130.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388442AbgEZBmi (ORCPT ); Mon, 25 May 2020 21:42:38 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R471e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01f04397;MF=laijs@linux.alibaba.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_---0Tzg711O_1590457355; Received: from localhost(mailfrom:laijs@linux.alibaba.com fp:SMTPD_---0Tzg711O_1590457355) by smtp.aliyun-inc.com(127.0.0.1); Tue, 26 May 2020 09:42:35 +0800 From: Lai Jiangshan To: linux-kernel@vger.kernel.org Cc: Lai Jiangshan , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , x86@kernel.org, Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Andrew Cooper , Juergen Gross , Brian Gerst Subject: [RFC PATCH V2 5/7] x86/entry: don't shift stack on #DB Date: Tue, 26 May 2020 01:42:19 +0000 Message-Id: <20200526014221.2119-6-laijs@linux.alibaba.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200526014221.2119-1-laijs@linux.alibaba.com> References: <20200525152517.GY325280@hirez.programming.kicks-ass.net> <20200526014221.2119-1-laijs@linux.alibaba.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org debug_enter() will disable #DB, there should be no recursive #DB. Cc: Andy Lutomirski Cc: Peter Zijlstra (Intel) Cc: Thomas Gleixner Cc: x86@kernel.org Signed-off-by: Lai Jiangshan --- arch/x86/entry/entry_64.S | 17 ----------------- arch/x86/kernel/asm-offsets_64.c | 1 - 2 files changed, 18 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 265ff97b3961..8ecaeee53653 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -396,11 +396,6 @@ SYM_CODE_END(\asmsym) idtentry \vector asm_\cfunc \cfunc has_error_code=0 .endm -/* - * MCE and DB exceptions - */ -#define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss_rw) + (TSS_ist + (x) * 8) - /** * idtentry_mce_db - Macro to generate entry stubs for #MC and #DB * @vector: Vector number @@ -416,10 +411,6 @@ SYM_CODE_END(\asmsym) * If hits in kernel mode then it needs to go through the paranoid * entry as the exception can hit any random state. No preemption * check on exit to keep the paranoid path simple. - * - * If the trap is #DB then the interrupt stack entry in the IST is - * moved to the second stack, so a potential recursion will have a - * fresh IST. */ .macro idtentry_mce_db vector asmsym cfunc SYM_CODE_START(\asmsym) @@ -445,16 +436,8 @@ SYM_CODE_START(\asmsym) movq %rsp, %rdi /* pt_regs pointer */ - .if \vector == X86_TRAP_DB - subq $DB_STACK_OFFSET, CPU_TSS_IST(IST_INDEX_DB) - .endif - call \cfunc - .if \vector == X86_TRAP_DB - addq $DB_STACK_OFFSET, CPU_TSS_IST(IST_INDEX_DB) - .endif - jmp paranoid_exit /* Switch to the regular task stack and use the noist entry point */ diff --git a/arch/x86/kernel/asm-offsets_64.c b/arch/x86/kernel/asm-offsets_64.c index c2a47016f243..472378330169 100644 --- a/arch/x86/kernel/asm-offsets_64.c +++ b/arch/x86/kernel/asm-offsets_64.c @@ -57,7 +57,6 @@ int main(void) BLANK(); #undef ENTRY - OFFSET(TSS_ist, tss_struct, x86_tss.ist); DEFINE(DB_STACK_OFFSET, offsetof(struct cea_exception_stacks, DB_stack) - offsetof(struct cea_exception_stacks, DB1_stack)); BLANK(); -- 2.20.1