Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp348095ybm; Fri, 29 May 2020 01:30:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzd/3IPIrPFVvf42yXc8bqvu6+i6e233KGv8Yonx5FvfHr4hs0Rl7Cx7xMJuUG9GP0T+zb5 X-Received: by 2002:a17:906:148b:: with SMTP id x11mr6417637ejc.282.1590741043052; Fri, 29 May 2020 01:30:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590741043; cv=none; d=google.com; s=arc-20160816; b=Rrkmqhxp/L2am5XzYIcJHzjLzCQxtdwKnbMRVMo0jGhz1Ar/RfUBgQmoQ4DO0P4SM/ tEAJ96KPoEej6D7W3WPJOPGZIC8vNS7vVtYwoieJ7F80pLni7/uIgqiBR0DemeWVw2Ma 4NcxjWj7SXtzZtW6QS6N/3tJjl4/L5ISZDXhqMJPXDFDYPLzkgTkPgUFPqnQNeZrRQSE tVT61Z+95vbfiKI3nH0qdWapmwWaf9HiJx32rjT9iv6S8O3M544m0aqgXt0M/FNQIbp2 yEmjTyJ++1Xqi6W7+Yzz+a/ry17cXohoAGKNxy727RP2pIBBpumLIMhrjlM7f6/Xvw8/ woAg== 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=ch3dwhc6CJaiqamQcr8A/9ekXr0yeBUUoDWJJJviRfU=; b=K5VcleE7q24grUQoUQAEU1pzVjOVa+zveWUJEg7Neu6D5d/ACoYAN8r0VZsFO6z92X 1qgqhL9/iGoCwcBB6IKDid4bkowsnjbrwiTojBWReMNxe8VVnYa+s1Ig0Fk5umS0jC2s cd+OEaspbtYBsjhTFUb3+3Xw/X59+0CYGFOJNMG5KSu2fl5eiCczhS2pog5e6kRhgX1d D3Q2x6bG2eQ+7J4UafnNktpX9dzTxgkiqo0Xmj6sCL4YX32UfmDGoiMS39ikzvLdz3Qh dDcXCZMGyE+Fc/Rky2oxnb2OvdzdLPrmoU2uJaNAMTSxSrQlmbzlf8Iw08hNj8fb39e+ OPBA== 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 jx4si4915859ejb.216.2020.05.29.01.30.20; Fri, 29 May 2020 01:30:43 -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 S1725913AbgE2I03 (ORCPT + 99 others); Fri, 29 May 2020 04:26:29 -0400 Received: from out30-42.freemail.mail.aliyun.com ([115.124.30.42]:34987 "EHLO out30-42.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725601AbgE2I01 (ORCPT ); Fri, 29 May 2020 04:26:27 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R131e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04426;MF=laijs@linux.alibaba.com;NM=1;PH=DS;RN=13;SR=0;TI=SMTPD_---0TzyIzVr_1590740783; Received: from localhost(mailfrom:laijs@linux.alibaba.com fp:SMTPD_---0TzyIzVr_1590740783) by smtp.aliyun-inc.com(127.0.0.1); Fri, 29 May 2020 16:26:24 +0800 From: Lai Jiangshan To: linux-kernel@vger.kernel.org Cc: Lai Jiangshan , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Alexandre Chartre , "Eric W. Biederman" , Jann Horn , Dave Hansen Subject: [PATCH V2 0/4] x86/entry: simply stack switching when exception on userspace Date: Fri, 29 May 2020 08:26:13 +0000 Message-Id: <20200529082618.1697-1-laijs@linux.alibaba.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <87mu5roov6.fsf@nanos.tec.linutronix.de> References: <87mu5roov6.fsf@nanos.tec.linutronix.de> 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 7f2590a110b8("x86/entry/64: Use a per-CPU trampoline stack for IDT entries") has resulted that when exception on userspace, the kernel (error_entry) always push the pt_regs to entry stack(sp0), and then copy them to the kernel stack. And recent x86/entry work makes interrupt also use idtentry and makes all the interrupt code save the pt_regs on the sp0 stack and then copy it to the thread stack like exception. This is hot path (page fault, ipi), such overhead should be avoided. And the original interrupt_entry directly switches to kernel stack and pushes pt_regs to kernel stack. We should do it for error_entry. This is the job of patch1. Patch 2-4 simply stack switching for .Lerror_bad_iret by just doing all the work in one function (fixup_bad_iret()). The patch set is based on tip/x86/entry (28447ea41542) (May 20). Changed from V1: based on tip/master -> based on tip/x86/entry patch 1 replaces the patch1,2 of V1, it borrows the original interrupt_entry's code into error_entry. patch2-4 is V1's patch3-5, unchanged (but rebased) Cc: Andy Lutomirski , Cc: Thomas Gleixner , Cc: Ingo Molnar , Cc: Borislav Petkov , Cc: x86@kernel.org, Cc: "H. Peter Anvin" , Cc: Peter Zijlstra , Cc: Alexandre Chartre , Cc: "Eric W. Biederman" , Cc: Jann Horn , Cc: Dave Hansen Lai Jiangshan (4): x86/entry: avoid calling into sync_regs() when entering from userspace x86/entry: directly switch to kernel stack when .Lerror_bad_iret x86/entry: remove unused sync_regs() x86/entry: don't copy to tmp in fixup_bad_iret arch/x86/entry/entry_64.S | 52 +++++++++++++++++++++++------------- arch/x86/include/asm/traps.h | 1 - arch/x86/kernel/traps.c | 42 ++++++++++++----------------- 3 files changed, 51 insertions(+), 44 deletions(-) -- 2.20.1