From owner-svn-src-head@freebsd.org Sat Jun 9 17:16:11 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B21310117BF; Sat, 9 Jun 2018 17:16:11 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ADB2379FBC; Sat, 9 Jun 2018 12:11:17 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (unknown [72.142.116.18]) by mail.baldwin.cx (Postfix) with ESMTPSA id E4B3110AFD4; Sat, 9 Jun 2018 08:11:16 -0400 (EDT) Subject: Re: svn commit: r334827 - in head/sys: amd64/amd64 arm/arm dev/hwpmc i386/i386 kern mips/atheros mips/cavium powerpc/powerpc sys To: Matthew Macy , Mark Johnston References: <201806080458.w584w3rn006318@repo.freebsd.org> <20180608143448.GB57885@pesky> <20180608162701.GA65388@pesky> Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org From: John Baldwin Message-ID: Date: Sat, 9 Jun 2018 08:11:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Sat, 09 Jun 2018 08:11:17 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 17:16:11 -0000 On 6/8/18 12:34 PM, Matthew Macy wrote: >> The fact that our NMI handler isn't re-entrant can lead to subtle >> problems. If while executing the NMI handler we hit a dtrace >> probe or DDB breakpoint, the iret executed upon return to the handler >> will re-enable NMIs. Then, if a second NMI arrives before the handler >> for the first has returned, the trapframe will be clobbered. Did you >> rule out an issue like this? > > No, but it happened instantly on all CPUs an a non-debug kernel 100% > of the time after I changed pmc_process_interrupt earlier this week. > My voodoo fix now avoids it. What you're describing sounds episodic > and doesn't sound like it would be fixed / worked around by my change. OTOH, a compiler bug will crop up in other places. It is best to run it to ground. Can you describe what the bug was in more detail? It would probably not be hard to come up with something you can run creduce against to get down to a test case. If you do that, the LLVM folks are quite helpful and able at fixing the issue which fixes it in more places than just here. -- John Baldwin