[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140714142111.GE17761@krava.redhat.com>
Date: Mon, 14 Jul 2014 16:21:11 +0200
From: Jiri Olsa <jolsa@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Jiri Olsa <jolsa@...nel.org>, linux-kernel@...r.kernel.org,
Alexander Yarygin <yarygin@...ux.vnet.ibm.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...nel.org>,
Paul Mackerras <paulus@...ba.org>
Subject: Re: [PATCH 2/5] perf: Destroy event's children on task exit
On Mon, Jul 14, 2014 at 03:35:42PM +0200, Peter Zijlstra wrote:
> On Mon, Jul 14, 2014 at 03:22:23PM +0200, Jiri Olsa wrote:
> > > > if we dont do it, the event stays installed without owner and
> > > > perf fork callback will be called and fail on permission checking
> > > > (because of owner == NULL) ... so yes, I think it's needed
> > >
> > > Oh, right. Alternatively, we don't need permission checking for inherits
> > > at all, if we're allowed to create the initial event, we should be good
> > > for inherits.
> >
> > I could adress that in follow up patch.. or you want this instead
> > of this one? IMO we should close those events anyway..
>
> I tend to agree that closing them all is nicer. But we need to be
> careful while doing it so as not to make the clone/fork path block on
> it.
>
> I _think_ it might be best to separate these two issues for the moment,
> so cure the reported problem by avoiding the permission check for
> inherited events -- IFF you agree with the previous argument that
> install_exec_creds() should be sufficient.
>
> And then so a patch playing games with perf_event_init_context()
> (clone/fork) vs perf_event_exit_task() (exit).
ook, will do
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists