On Sat, Jun 9, 2018 at 10:51 Mark Johnston <ma...@freebsd.org> wrote:
> On Sat, Jun 09, 2018 at 08:11:15AM -0400, John Baldwin wrote: > > 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. > > The bug is the rdtscp() intrinsic added in r334746 is wrong. It was just > copied from rdtsc(), but unlike rdtsc, rdtscp clobbers rcx, which is the > register containing the tf pointer. > Thanks for identifying that. Are you going to update it? -M _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"