From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753541AbbIKQc5 (ORCPT ); Fri, 11 Sep 2015 12:32:57 -0400 Received: from mail-pa0-f49.google.com ([209.85.220.49]:36416 "EHLO mail-pa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752152AbbIKQcy (ORCPT ); Fri, 11 Sep 2015 12:32:54 -0400 Date: Sat, 12 Sep 2015 01:29:34 +0900 From: Namhyung Kim To: =?utf-8?B?5bmz5p2+6ZuF5bezIC8gSElSQU1BVFXvvIxNQVNBTUk=?= Cc: "Wangnan (F)" , Arnaldo Carvalho de Melo , Ingo Molnar , Peter Zijlstra , Jiri Olsa , LKML , "pi3orama@163.com" Subject: Re: Re: [PATCH v2 1/5] perf probe: Split add_perf_probe_events() Message-ID: <20150911162934.GE3447@danjae.kornet> References: <1441368963-11565-1-git-send-email-namhyung@kernel.org> <55EBEF99.8010506@huawei.com> <20150910022325.GA32720@danjae.kornet> <50399556C9727B4D88A595C8584AAB375252011D@GSjpTKYDCembx32.service.hitachi.net> <20150910064055.GA18425@danjae.kornet> <50399556C9727B4D88A595C8584AAB37525207EE@GSjpTKYDCembx32.service.hitachi.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <50399556C9727B4D88A595C8584AAB37525207EE@GSjpTKYDCembx32.service.hitachi.net> User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 10, 2015 at 08:10:16AM +0000, 平松雅巳 / HIRAMATU，MASAMI wrote: > Hi Namhyung, > > From: Namhyung Kim [mailto:namhyung@gmail.com] On Behalf Of Namhyung Kim > > > >Hi Masami, > > > >On Thu, Sep 10, 2015 at 05:00:07AM +0000, 平松雅巳 / HIRAMATU，MASAMI wrote: > >> >From: Namhyung Kim [mailto:namhyung@gmail.com] On Behalf Of Namhyung Kim > >> >The del_perf_probe_events() uses strfilter, but I think it can be > >> >problematic if other instances or users are using similar events at > >> >the same time. > >> > >> Yeah, since perf probe doesn't lock the ftrace, there should be a > >> timing bug, but it can be fixed easily by ignoring -ENOENT. :) > > > >By ignoring -ENOENT? Are you saying that there's a race between two > >deleters? Yes, of course, but I think that the bug will hit an adder > >and a deleter especially if automatic probing is used (by eBPF and/or > >SDT recording). > > So, I don't think we need the automatic event removing. Instead, I'd like to > suggest to keep it on the list. But why? Do you want reuse the probes for next record session? I think if something is generated automatically, it should be removed automatically.. Thanks, Namhyung