From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753818AbbLIK4X (ORCPT <rfc822;w@1wt.eu>);
	Wed, 9 Dec 2015 05:56:23 -0500
Received: from casper.infradead.org ([85.118.1.10]:43649 "EHLO
	casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753238AbbLIK4W (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 9 Dec 2015 05:56:22 -0500
Date: Wed, 9 Dec 2015 11:56:18 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
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
Message-ID: <20151209105618.GN6356@twins.programming.kicks-ass.net>
References: <1449138762-15194-1-git-send-email-alexander.shishkin@linux.intel.com>
 <1449138762-15194-5-git-send-email-alexander.shishkin@linux.intel.com>
 <20151204170206.GI17308@twins.programming.kicks-ass.net>
 <87si3cx7ts.fsf@ashishki-desk.ger.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87si3cx7ts.fsf@ashishki-desk.ger.corp.intel.com>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Dec 09, 2015 at 11:57:51AM +0200, Alexander Shishkin wrote:
> 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().

Well, you had to drop it because you wanted to acquire the ctx::mutex,
but if we drop that requirement, as we must per the other emails, then
this should indeed be possible.

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

Correct.

> 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);

I'm not sure about the different semantics between event->cpu == -1 and
not, but yes, something along those likes.