All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Stephane Eranian <eranian@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Vince Weaver <vincent.weaver@maine.edu>,
	Jiri Olsa <jolsa@redhat.com>, "Liang, Kan" <kan.liang@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Hunter <ahh@google.com>,
	Maria Dimakopoulou <maria.n.dimakopoulou@gmail.com>
Subject: Re: [PATCH 01/10] perf,x86: Fix event/group validation
Date: Fri, 22 May 2015 11:46:19 +0200	[thread overview]
Message-ID: <20150522094619.GA18829@gmail.com> (raw)
In-Reply-To: <CABPqkBQ9yGaXtHomrvBtjXs0K4fvgcqceOpM2sTYSSg+F+6_dg@mail.gmail.com>


* Stephane Eranian <eranian@google.com> wrote:

> On Thu, May 21, 2015 at 11:49 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> >
> > * Stephane Eranian <eranian@google.com> wrote:
> >
> > > On Thu, May 21, 2015 at 7:03 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > > > On Thu, 2015-05-21 at 06:36 -0700, Stephane Eranian wrote:
> > > >> On Thu, May 21, 2015 at 6:29 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > > >> > On Thu, 2015-05-21 at 06:27 -0700, Stephane Eranian wrote:
> > > >> >> Or are you talking about a preemption while executing x86_schedule_events()?
> > > >> >
> > > >> > That.
> > > >> >
> > > >> > And we can of course cure that by an earlier patch I send; but I find it
> > > >> > a much simpler rule to just never allow modifying global state for
> > > >> > validation.
> > > >>
> > > >> I can see  validation being preempted, but not the context switch code path.
> > > >> Is that what you are talking about?
> > > >>
> > > >> You are saying validate_group() is in the middle of x86_schedule_events()
> > > >> using fake_cpuc, when it gets preempted. The context switch code when it loads
> > > >> the new thread's PMU state calls x86_schedule_events() which modifies the
> > > >> cpuc->event_list[]->hwc. But this is cpuc vs. fake_cpuc again. So yes, the calls
> > > >> nest but they do not touch the same state.
> > > >
> > > > They both touch event->hw->constraint.
> > > >
> > > >>  And when you eventually come back
> > > >> to validate_group() you are back to using the fake_cpuc. So I am still not clear
> > > >> on how the corruption can happen.
> > > >
> > > > validate_group()
> > > >   x86_schedule_events()
> > > >     event->hw.constraint = c; # store
> > > >
> > > >      <context switch>
> > > >        perf_task_event_sched_in()
> > > >          ...
> > > >            x86_schedule_events();
> > > >              event->hw.constraint = c2; # store
> > > >
> > > >              ...
> > > >
> > > >              put_event_constraints(event); # assume failure to schedule
> > > >                intel_put_event_constraints()
> > > >                  event->hw.constraint = NULL;
> > > >
> > > >       <context switch end>
> > > >
> > > >     c = event->hw.constraint; # read -> NULL
> > > >
> > > >     if (!test_bit(hwc->idx, c->idxmsk)) # <- *BOOM* NULL deref
> > > >
> > > >
> > > > This in particular is possible when the event in question is a cpu-wide
> > > > event and group-leader, where the validate_group() tries to add an event
> > > > to the group.
> > >
> > > Ok, I think I get it now. It is not related to fake_cpuc vs. cpuc,
> > > it is related to the fact that the constraint is cached in the event
> > > struct itself and that one is shared between validate_group() and
> > > x86_schedule_events() because cpu_hw_event->event_list[] is an array
> > > of pointers to events and not an array of events.
> >
> > Btw., comments and the code structure should be greatly enhanced 
> > to make all that very clear and hard to mess up.
> >
> Peter and I will clean this up.

Great, thanks!

	Ingo

  reply	other threads:[~2015-05-22  9:46 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-21 11:17 [PATCH 00/10] Various x86 pmu scheduling patches Peter Zijlstra
2015-05-21 11:17 ` [PATCH 01/10] perf,x86: Fix event/group validation Peter Zijlstra
2015-05-21 12:35   ` Stephane Eranian
2015-05-21 12:56     ` Peter Zijlstra
2015-05-21 13:07       ` Stephane Eranian
2015-05-21 13:09         ` Peter Zijlstra
2015-05-21 13:18           ` Stephane Eranian
2015-05-21 13:20             ` Peter Zijlstra
2015-05-21 13:27               ` Stephane Eranian
2015-05-21 13:29                 ` Peter Zijlstra
2015-05-21 13:36                   ` Stephane Eranian
2015-05-21 14:03                     ` Peter Zijlstra
2015-05-21 15:11                       ` Stephane Eranian
2015-05-22  6:49                         ` Ingo Molnar
2015-05-22  9:26                           ` Stephane Eranian
2015-05-22  9:46                             ` Ingo Molnar [this message]
2015-05-21 14:53   ` Peter Zijlstra
2015-05-21 15:42     ` Stephane Eranian
2015-08-21 20:31   ` Sasha Levin
2015-09-10  4:48     ` Sasha Levin
2015-09-10  8:54     ` Stephane Eranian
2015-09-10 10:01       ` Peter Zijlstra
2015-05-21 11:17 ` [PATCH 02/10] perf/x86: Improve HT workaround GP counter constraint Peter Zijlstra
2015-05-22 10:04   ` Stephane Eranian
2015-05-22 11:21     ` Peter Zijlstra
2015-05-22 11:24       ` Stephane Eranian
2015-05-22 11:28       ` Peter Zijlstra
2015-05-22 12:35         ` Stephane Eranian
2015-05-22 12:53           ` Peter Zijlstra
2015-05-22 12:55             ` Stephane Eranian
2015-05-22 12:59               ` Peter Zijlstra
2015-05-22 13:05                 ` Stephane Eranian
2015-05-22 13:07                   ` Stephane Eranian
2015-05-22 13:25                     ` Peter Zijlstra
2015-05-22 13:29                       ` Stephane Eranian
2015-05-22 13:36                         ` Peter Zijlstra
2015-05-22 13:40                           ` Stephane Eranian
2015-05-22 13:48                             ` Peter Zijlstra
2015-05-23  8:26                               ` Ingo Molnar
2015-05-22 13:25                   ` Peter Zijlstra
2015-05-22 13:10                 ` Peter Zijlstra
2015-05-21 11:17 ` [PATCH 03/10] perf/x86: Correct local vs remote sibling state Peter Zijlstra
2015-05-21 13:31   ` Stephane Eranian
2015-05-21 14:10     ` Peter Zijlstra
2015-05-21 11:17 ` [PATCH 04/10] perf/x86: Use lockdep Peter Zijlstra
2015-05-21 11:17 ` [PATCH 05/10] perf/x86: Simplify dynamic constraint code somewhat Peter Zijlstra
2015-05-21 11:17 ` [PATCH 06/10] perf/x86: Make WARNs consistent Peter Zijlstra
2015-05-21 11:17 ` [PATCH 07/10] perf/x86: Move intel_commit_scheduling() Peter Zijlstra
2015-05-21 11:17 ` [PATCH 08/10] perf/x86: Remove pointless tests Peter Zijlstra
2015-05-21 13:24   ` Stephane Eranian
2015-05-21 11:17 ` [PATCH 09/10] perf/x86: Remove intel_excl_states::init_state Peter Zijlstra
2015-05-21 13:39   ` Stephane Eranian
2015-05-21 14:12     ` Peter Zijlstra
2015-05-21 11:17 ` [PATCH 10/10] perf,x86: Simplify logic Peter Zijlstra
2015-05-21 11:48 ` [PATCH 00/10] Various x86 pmu scheduling patches Stephane Eranian
2015-05-21 12:53   ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150522094619.GA18829@gmail.com \
    --to=mingo@kernel.org \
    --cc=ahh@google.com \
    --cc=eranian@google.com \
    --cc=jolsa@redhat.com \
    --cc=kan.liang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maria.n.dimakopoulou@gmail.com \
    --cc=peterz@infradead.org \
    --cc=vincent.weaver@maine.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.