From owner-svn-src-all@freebsd.org Sat Feb 25 07:51:19 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 38AEECECBB9; Sat, 25 Feb 2017 07:51:19 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EC15A1BD5; Sat, 25 Feb 2017 07:51:17 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA07343; Sat, 25 Feb 2017 09:51:09 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1chX8H-00025d-9b; Sat, 25 Feb 2017 09:51:09 +0200 Subject: Re: svn commit: r314216 - head/sys/x86/x86 To: "Jonathan T. Looney" , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org References: <201702241856.v1OIu150004903@repo.freebsd.org> From: Andriy Gapon Message-ID: Date: Sat, 25 Feb 2017 09:50:32 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <201702241856.v1OIu150004903@repo.freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: Sat, 25 Feb 2017 07:51:19 -0000 On 24/02/2017 20:56, Jonathan T. Looney wrote: > 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. Just curious if you were able to find out what code caused those shootdowns to be sent. It's pretty unusual for the after-panic code to do things like that. > 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. > */ > -- Andriy Gapon