Received: by 10.223.164.202 with SMTP id h10csp1702108wrb; Mon, 27 Nov 2017 06:22:52 -0800 (PST) X-Google-Smtp-Source: AGs4zMZlLVlPXor1WkkwZzh5IdEf0zDlSNi0brGfmrNsDWger6XLR2BJDAsiWvYLor9F4nKPFAn9 X-Received: by 10.98.245.221 with SMTP id b90mr37273535pfm.203.1511792572800; Mon, 27 Nov 2017 06:22:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511792572; cv=none; d=google.com; s=arc-20160816; b=HzsPbBbakPYvVkF+KaMaAFW30oGSmxFm5QX4RXj/8fzH411K+cuPJxSpldK2L4a2UV V+AKkul9kTy5DtfQ6o01DTjspeMzoMP8+xhZibvRRPm/eXZSOUkZ+3vncakTq3qeNQ2N RAdECJCF5Z5xUMibn0Ok9kNiY5pe6xAPPlL8lWs5nUonSbkscXfx/ixRlg6RwiPNkHO2 +O2/wHfYHvNuSFK+ue2nat6VDWYhc7oieqCROAZKT0uGLzej3TQEiF1kwGHQ/aGPnkBY funIYO/+6o/t3ZMYDjf/1Win387RWgdSN96D7jNYqVawE+/rqgkAOTzyVJ8D3Wba8Zax ufFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=bE6RVqXy7aYHNCTP21HZ/yZ7GMcf8i4p0KzYDGggibc=; b=SOUFUCE7hO8tLGKXRa5OId8GhMCR3YdnDvsmcmibuVv+CdKpzWsGFCVDnWcxXirwDV AB1INWYWmacyL8dQY5HhrYen/49TyG03Kcw19bEDkGGHUdKbmZw9N7Cdb5QhZRz6uEG/ 14KZEBtBT8YWL/hZ37HyCXtgGjY5gzhyShSk9qHpFd1PiGP6cKK5eOfF1u08q5+ob8cQ fwPqiNyhJ+ZR1WAT6mDRcAp0Po+fgrZES6fOsBSc0dxpC/g/30LEOZKwYTOjBC754A1r 4RPVPgI4Cn4WYh+YAFdoukyQiYVO6g9tLU8MOYIdJo4RZMc+Vk3tKq45eIs8+vffAvO0 AKvg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q61si23490167plb.581.2017.11.27.06.22.41; Mon, 27 Nov 2017 06:22:52 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752578AbdK0OVs (ORCPT + 77 others); Mon, 27 Nov 2017 09:21:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38512 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751311AbdK0OVp (ORCPT ); Mon, 27 Nov 2017 09:21:45 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6C6D38123D; Mon, 27 Nov 2017 14:21:45 +0000 (UTC) Received: from dhcp-12-107.nay.redhat.com (dhcp-12-107.nay.redhat.com [10.66.12.107]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C37A6600D5; Mon, 27 Nov 2017 14:21:42 +0000 (UTC) From: Chunyu Hu To: tglx@linutronix.de Cc: mingo@kernel.org, hpa@zytor.com, peterz@infradead.org, luto@kernel.org, bp@alien8.de, rostedt@goodmis.org, linux-kernel@vger.kernel.org Subject: [PATCH] x86/idt: load idt early in start_secondary Date: Mon, 27 Nov 2017 22:21:39 +0800 Message-Id: <1511792499-4073-1-git-send-email-chuhu@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 27 Nov 2017 14:21:45 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org For ap, idt is first loaded in cpu_init() with load_current_idt(), that is to say, no exception can be handled before there. And then the idt_table has been completed by the bp. While there are some WARNs which needs the UD exception handling in the early boot code might be triggered when something uexpected happens during boot. In that case, cpu would fail to boot as the exception can't be handled. A WARNing during boot is not usually meaning the system could not boot. One use case is when ftrace=function is setup in kernel cmdline, the ftrace callback function will be called for every traced function. And in my case, the first traced function is load_ucode_ap. And there are WARN()s in function trace callback handling, it failed to reboot as one of the WARN()s is triggered before load_current_idt() executed. To make WARN()s can work earlier to ap, we load the idt_table early in start_secondary, and keep the second time idt load in cpu_init, as there is a load_ucode_ap() there. Signed-off-by: Chunyu Hu --- arch/x86/kernel/smpboot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index 3d01df7..05a97d5 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -237,7 +237,7 @@ static void notrace start_secondary(void *unused) load_cr3(swapper_pg_dir); __flush_tlb_all(); #endif - + load_current_idt(); cpu_init(); x86_cpuinit.early_percpu_clock_init(); preempt_disable(); -- 1.8.3.1 From 1585311772355695264@xxx Tue Nov 28 12:12:00 +0000 2017 X-GM-THRID: 1585305005485339652 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread