All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, vince@deater.net,
	eranian@google.com, johannes@sipsolutions.net,
	Arnaldo Carvalho de Melo <acme@infradead.org>
Subject: Re: [PATCH 4/7] perf: Free aux pages in unmap path
Date: Wed, 09 Dec 2015 11:57:51 +0200	[thread overview]
Message-ID: <87si3cx7ts.fsf@ashishki-desk.ger.corp.intel.com> (raw)
In-Reply-To: <20151204170206.GI17308@twins.programming.kicks-ass.net>

Peter Zijlstra <peterz@infradead.org> writes:

> Yuck, nasty problem. Also, I think its broken. By not having
> mmap_mutex around the whole thing, notably rb_free_aux(), you can race
> against mmap().
>
> What seems possible now is that:
>
> 	mmap(aux); // rb->aux_mmap_count == 1
> 	munmap(aux)
> 	  atomic_dec_and_mutex_lock(&rb->aux_mmap_count, &event->mmap_mutex); // == 0
>
> 	  mutex_unlock(&event->mmap_mutex);
>
> 					mmap(aux)
> 					  if (rb_has_aux())
> 					    atomic_inc(&rb->aux_mmap_count); // == 1
>
> 	  rb_free_aux(); // oops!!

Wait, this isn't actually a problem, we can hold mmap_mutex over
rb_free_aux(), as we actually already do in current code. My patch did
it wrongly though, but there's really no reason to drop the mutex before
rb_free_aux().

> So I thought that pulling all the aux bits out from the ring_buffer
> struct, such that we have rb->aux, would solve the issue in that we can
> then fix mmap() to have the same retry loop as for event->rb.
>
> And while that fixes that race (I almost had that patch complete -- I
> might still send it out, just so you can see what it looks like), it
> doesn't solve the complete problem I don't think.

I was toying with that some time ago, but I couldn't really see the
benefits that would justify the hassle.

> Because in that case, you want the event to start again on the new
> buffer, and I think its possible we end up calling ->start() before
> we've issued the ->stop() and that would be BAD (tm).

So if we just hold the mmap_mutex over rb_free_aux(), this won't
happen, right?

> The only solution I've come up with is:
>
> 	struct rb_aux *aux = rb->aux;
>
> 	if (aux && vma->vm_pgoff == aux->pgoff) {
> 		ctx = perf_event_ctx_lock(event);
> 		if (!atomic_dec_and_mutex_lock(&aux->mmap_count, &event->mmap_mutex) {
> 			/* we now hold both ctx::mutex and event::mmap_mutex */
> 			rb->aux = NULL;
> 			ring_buffer_put(rb); /* aux had a reference */
> 			_perf_event_stop(event);

Here we really need to ensure that none of the events on the
rb->event_list is running, not just the parent, and that still presents
complications wrt irqsave rb->event_lock even with your new idea for
perf_event_stop().

How about something like this to stop the writers:

static int __ring_buffer_output_stop(void *info)
{
	struct ring_buffer *rb = info;
	struct perf_event *event;
 
	spin_lock(&rb->event_lock);
	list_for_each_entry_rcu(event, &rb->event_list, rb_entry) {
		if (event->state != PERF_EVENT_STATE_ACTIVE)
			continue;

		event->pmu->stop(event, PERF_EF_UPDATE);
	}
	spin_unlock(&rb->event_lock);

	return 0;
}

static void perf_event_output_stop(struct perf_event *event)
{
	struct ring_buffer *rb = event->rb;

	lockdep_assert_held(&event->mmap_mutex);

	if (event->cpu == -1)
		perf_event_stop(event);

	cpu_function_call(event->cpu, __ring_buffer_output_stop, rb);
}
 
And then in the mmap_close:

	if (rb_has_aux(rb) && vma->vm_pgoff == rb->aux_pgoff &&
	    atomic_dec_and_mutex_lock(&rb->aux_mmap_count, &event->mmap_mutex)) {
		perf_event_output_stop(event);

                /* undo the mlock accounting here */

 		rb_free_aux(rb);
               	mutex_unlock(&event->mmap_mutex);
	}

Regards,
--
Alex

  parent reply	other threads:[~2015-12-09  9:58 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-03 10:32 [PATCH 0/7] perf: Untangle aux refcounting Alexander Shishkin
2015-12-03 10:32 ` [PATCH 1/7] perf: Refuse to begin aux transaction after aux_mmap_count drops Alexander Shishkin
2015-12-03 10:32 ` [PATCH 2/7] perf: Generalize task_function_call()ers Alexander Shishkin
2015-12-03 17:34   ` Peter Zijlstra
2015-12-08 16:42     ` Alexander Shishkin
2015-12-08 16:57       ` Peter Zijlstra
2015-12-17 13:40         ` Peter Zijlstra
2015-12-17 14:25           ` Alexander Shishkin
2015-12-17 15:07             ` Peter Zijlstra
2015-12-18  9:01               ` Peter Zijlstra
2015-12-18 15:07                 ` Alexander Shishkin
2015-12-18 16:47                   ` Peter Zijlstra
2015-12-18 17:41                     ` Alexander Shishkin
2015-12-21 14:39                 ` Alexander Shishkin
2016-01-11 10:44                 ` Alexander Shishkin
2015-12-03 10:32 ` [PATCH 3/7] perf: Add a helper to stop running events Alexander Shishkin
2015-12-03 10:32 ` [PATCH 4/7] perf: Free aux pages in unmap path Alexander Shishkin
2015-12-04 17:02   ` Peter Zijlstra
2015-12-04 22:17     ` Peter Zijlstra
2015-12-07 16:16       ` Peter Zijlstra
2015-12-09  9:57     ` Alexander Shishkin [this message]
2015-12-09 10:56       ` Peter Zijlstra
2015-12-10 11:20         ` Alexander Shishkin
2015-12-10 12:58           ` Alexander Shishkin
2015-12-03 10:32 ` [PATCH 5/7] perf: Document aux api usage Alexander Shishkin
2015-12-03 20:36   ` Mathieu Poirier
2015-12-03 10:32 ` [PATCH 6/7] perf/x86/intel/pt: Move transaction start/stop to pmu start/stop callbacks Alexander Shishkin
2015-12-03 10:32 ` [PATCH 7/7] perf/x86/intel/bts: Move transaction start/stop to " Alexander Shishkin

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=87si3cx7ts.fsf@ashishki-desk.ger.corp.intel.com \
    --to=alexander.shishkin@linux.intel.com \
    --cc=acme@infradead.org \
    --cc=eranian@google.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=vince@deater.net \
    /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.