Re: [PATCH 1/8] perf/x86/intel: Fix memory corruption

[Peter Zijlstra]

On Mon, Mar 18, 2019 at 11:29:25PM -0700, Stephane Eranian wrote:

> > --- a/arch/x86/events/intel/core.c
> > +++ b/arch/x86/events/intel/core.c
> > @@ -3410,7 +3410,7 @@ tfa_get_event_constraints(struct cpu_hw_
> >         /*
> >          * Without TFA we must not use PMC3.
> >          */
> > -       if (!allow_tsx_force_abort && test_bit(3, c->idxmsk)) {
> > +       if (!allow_tsx_force_abort && test_bit(3, c->idxmsk) && idx >= 0) {
> >                 c = dyn_constraint(cpuc, c, idx);
> >                 c->idxmsk64 &= ~(1ULL << 3);
> >                 c->weight--;
> >
> >

> I was not cc'd on the patch that added  allow_tsx_force_abort, so I

Yeah, that never was public :-( I didn't particularly like that, but
that's the way it is.

> will give some comments here.

> If I understand the goal of the control parameter it is to turn on/off
> the TFA workaround and thus determine whether or not PMC3 is
> available. I don't know why you would need to make this a runtime
> tunable.

Not quite; the control on its own doesn't directly write the MSR. And
even when the work-around is allowed, we'll not set the MSR unless there
is also demand for PMC3.

It is a runtime tunable because boot parameters suck.

> That seems a bit dodgy. But given the code you have here right now, we
> have to deal with it. A sysadmin could flip the control at any time,
> including when PMC3 is already in used by some events. I do not see
> the code that schedules out all the events on all CPUs once PMC3
> becomes unavailable. You cannot just rely on the next context-switch
> or timer tick for multiplexing.

Yeah, meh. You're admin, you can 'fix' it. In practise I don't expect
most people to care about the knob, and the few people that do, should
be able to make it work.