From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751518AbdJBTe4 (ORCPT ); Mon, 2 Oct 2017 15:34:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:38392 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751062AbdJBTez (ORCPT ); Mon, 2 Oct 2017 15:34:55 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 38E45218C7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=acme@kernel.org Date: Mon, 2 Oct 2017 16:34:53 -0300 From: Arnaldo Carvalho de Melo To: "Liang, Kan" Cc: "peterz@infradead.org" , "mingo@redhat.com" , "linux-kernel@vger.kernel.org" , "jolsa@kernel.org" , "namhyung@kernel.org" , "Hunter, Adrian" , "Odzioba, Lukasz" , "wangnan0@huawei.com" , "hekuang@huawei.com" , "ast@kernel.org" , "ak@linux.intel.com" Subject: Re: [PATCH RFC V4 1/6] perf tools: lock to protect namespaces and comm list Message-ID: <20171002193453.GD2869@kernel.org> References: <1506696477-146932-1-git-send-email-kan.liang@intel.com> <1506696477-146932-2-git-send-email-kan.liang@intel.com> <20171002180528.GC2869@kernel.org> <37D7C6CF3E00A74B8858931C1DB2F077537CD725@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F077537CD725@SHSMSX103.ccr.corp.intel.com> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.9.0 (2017-09-02) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Mon, Oct 02, 2017 at 07:14:10PM +0000, Liang, Kan escreveu: > > Em Fri, Sep 29, 2017 at 07:47:52AM -0700, kan.liang@intel.com escreveu: > > > From: Kan Liang > > > > > > Add two locks to protect namespaces_list and comm_list. > > > > > > The lock is only needed for multithreaded code, so using mutex > > > wrappers provided by perf tool. > > > > > > Not all the comm_list/namespaces_list accessing are protected, e.g. > > > thread__exec_comm. Because the multithread code for perf top event > > > synthesizing does not touch them. They don't need a lock. > > > > They don't need a lock _now_, ok I think we can proceed that way, this cset > > should serve as a warning to people working in further multithreading perf. > > > > Do I need to add some comments in the code to give a warning? Maybe, but then one can use 'git blame' and see the comments on the patch introducing the locking. BTW, I'm applied and tested it, pushed to acme/perf/core. - Arnaldo