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 S1756888AbcAYLsw (ORCPT <rfc822;w@1wt.eu>);
	Mon, 25 Jan 2016 06:48:52 -0500
Received: from casper.infradead.org ([85.118.1.10]:39485 "EHLO
	casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1756021AbcAYLst (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Jan 2016 06:48:49 -0500
Date: Mon, 25 Jan 2016 12:48:46 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Ingo Molnar <mingo@redhat.com>, linux-kernel@vger.kernel.org,
        vince@deater.net, eranian@google.com,
        Arnaldo Carvalho de Melo <acme@infradead.org>,
        Jiri Olsa <jolsa@kernel.org>
Subject: Re: [PATCH v2] perf: Synchronously cleanup child events
Message-ID: <20160125114846.GW6357@twins.programming.kicks-ass.net>
References: <20160118144410.GS6357@twins.programming.kicks-ass.net>
 <1453216354-9282-1-git-send-email-alexander.shishkin@linux.intel.com>
 <20160119200558.GC6357@twins.programming.kicks-ass.net>
 <87lh7hhmnn.fsf@ashishki-desk.ger.corp.intel.com>
 <20160122123847.GS6357@twins.programming.kicks-ass.net>
 <20160122194403.GC11338@ast-mbp.thefacebook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160122194403.GC11338@ast-mbp.thefacebook.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 Fri, Jan 22, 2016 at 11:44:03AM -0800, Alexei Starovoitov wrote:
> On Fri, Jan 22, 2016 at 01:38:47PM +0100, Peter Zijlstra wrote:
> > On Fri, Jan 22, 2016 at 01:35:40PM +0200, Alexander Shishkin wrote:
> > > Peter Zijlstra <peterz@infradead.org> writes:
> > > 
> > > > So I think there's a number of problems still :-(
> 
> I've been looking at how perf_event->owner is handled and couldn't
> figure out how you deal with the case of passing perf_event_fd via scm_rights.
> It seems one process can open an event, pass it to another process,
> but when current process exists owner will still point to dead task,
> since refcount > 0.
> Which part am I missing?

Nothing, you raised a good point. I think this shows we cannot link
!event->owner to an event being 'dead'.

If we keep these two states separate, the scm_rights thing should work
again.