From owner-svn-src-all@freebsd.org Fri Feb 24 18:56:02 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3CBBDCEC8DB; Fri, 24 Feb 2017 18:56:02 +0000 (UTC) (envelope-from jtl@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 09D14B14; Fri, 24 Feb 2017 18:56:01 +0000 (UTC) (envelope-from jtl@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id v1OIu1dO004904; Fri, 24 Feb 2017 18:56:01 GMT (envelope-from jtl@FreeBSD.org) Received: (from jtl@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id v1OIu150004903; Fri, 24 Feb 2017 18:56:01 GMT (envelope-from jtl@FreeBSD.org) Message-Id: <201702241856.v1OIu150004903@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: jtl set sender to jtl@FreeBSD.org using -f From: "Jonathan T. Looney" Date: Fri, 24 Feb 2017 18:56:01 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r314216 - head/sys/x86/x86 X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 18:56:02 -0000 Author: jtl Date: Fri Feb 24 18:56:00 2017 New Revision: 314216 URL: https://svnweb.freebsd.org/changeset/base/314216 Log: We have seen several cases recently where we appear to get a double-fault: We have an original panic. Then, instead of writing the core to the dump device, the kernel has a second panic: "smp_targeted_tlb_shootdown: interrupts disabled". This change is an attempt to fix that second panic. When the other CPUs are stopped, we can't notify them of the TLB shootdown, so we skip that operation. However, when the CPUs come back up, we invalidate the TLB to ensure they correctly observe any changes to the page mappings. Reviewed by: kib Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D9786 Modified: head/sys/x86/x86/mp_x86.c Modified: head/sys/x86/x86/mp_x86.c ============================================================================== --- head/sys/x86/x86/mp_x86.c Fri Feb 24 17:36:55 2017 (r314215) +++ head/sys/x86/x86/mp_x86.c Fri Feb 24 18:56:00 2017 (r314216) @@ -45,6 +45,7 @@ __FBSDID("$FreeBSD$"); #ifdef GPROF #include #endif +#include #include #include #include @@ -1269,6 +1270,12 @@ cpustop_handler_post(u_int cpu) CPU_CLR_ATOMIC(cpu, &started_cpus); CPU_CLR_ATOMIC(cpu, &stopped_cpus); + /* + * We don't broadcast TLB invalidations to other CPUs when they are + * stopped. Hence, we clear the TLB before resuming. + */ + invltlb_glob(); + #if defined(__amd64__) && defined(DDB) amd64_db_resume_dbreg(); #endif @@ -1427,6 +1434,10 @@ smp_targeted_tlb_shootdown(cpuset_t mask uint32_t generation; int cpu; + /* It is not necessary to signal other CPUs while in the debugger. */ + if (kdb_active || panicstr != NULL) + return; + /* * Check for other cpus. Return if none. */