svn commit: r334827 - in head/sys: amd64/amd64 arm/arm dev/hwpmc i386/i386 kern mips/atheros mips/cavium powerpc/powerpc sys

[Matthew Macy]

On Sat, Jun 9, 2018 at 10:51 Mark Johnston <markj at 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