From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 716B9C4332F for ; Sun, 12 Dec 2021 13:47:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231281AbhLLNrm (ORCPT ); Sun, 12 Dec 2021 08:47:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60698 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231254AbhLLNri (ORCPT ); Sun, 12 Dec 2021 08:47:38 -0500 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7DF96C0613FE for ; Sun, 12 Dec 2021 05:47:37 -0800 (PST) Received: by mail-ed1-x52c.google.com with SMTP id y13so43692413edd.13 for ; Sun, 12 Dec 2021 05:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=rK1kg3BdhZ6vLWzAC/NJououZjpKNDWOeE95mIOHLwM=; b=ldSwe0RjVRHsN8mMDq8u31wWcE0Ai3OmoE/gzxo9Ee3YJREu6xjReDIro45Uk+mZC2 PUXywo8tMs4T/Z4qdwrFNYHQJqX33Vf94B7C+Cn2wILZncUXqKm2UaB9Ce3cBG94cD8Z MGUbvOpVuxJxWf16wDm5LzPjN4vKr7vWLQSixfUtE/MPP5NYnx9RoVcl69krk4qWV7QO RgZZ3FcjcJxFsmliE3cuLA0+KRzOzL2sKhDiiO5gaCX6X0dr2iAYBq6sTJd768vj0mT5 9fc5XLoSOOq31k7MYQg7DWH2doGIhUEuYsc5vrpgrU8K8yMOBdC7ZwhpHa5R8FAFNCDS UEag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=rK1kg3BdhZ6vLWzAC/NJououZjpKNDWOeE95mIOHLwM=; b=wFk63R1GjdYfKaphdhaS+KAgdVp0pSPVn2j6IQng47usXZieKJRSI1blgaJVd62lg4 pVAeE1Nos1Y//0MbeEHoS/PHI7RSZ7vCYogBABjbAAPa80ZYfs1ihoVDbsnRhRN2xpWB HXb/7xLAr65aytniF401T1ELNxSbanb0Sbjb0KYXJ88cvREEH50eQJI34dOzgp7LPqqs 8181778RU4gzc57LjlCiNvdjCMZexJimosGh1zAjFL94QjmYGLd2pv2B1YJCnaMSsmLS dJBhofPCWZvKxF0yIXtQ207K64N+69PyBxRpkaBndVV5yqvhBVl2airuqa0iJIgNaOVV 8kTw== X-Gm-Message-State: AOAM533cHJmDx/KXrK2R77bwc0q5IvG0qNFxXWUcsx+IttWldQCGW7oD FgLI2+tI9XZtEP9ZGpEuJpCt8w== X-Google-Smtp-Source: ABdhPJzjWwtlbpO7/42zB/Kq1uP/6C0lh8G/iFpj6GJmFlQsf7lZb5/ZwrXmB5hFGU/usI1ePolpfw== X-Received: by 2002:a50:e0c9:: with SMTP id j9mr56003635edl.336.1639316855926; Sun, 12 Dec 2021 05:47:35 -0800 (PST) Received: from localhost ([104.245.96.202]) by smtp.gmail.com with ESMTPSA id i4sm4082449ejz.122.2021.12.12.05.47.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Dec 2021 05:47:35 -0800 (PST) From: Leo Yan To: Arnaldo Carvalho de Melo , Jiri Olsa , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Namhyung Kim , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Jin Yao , John Garry , Yonatan Goldschmidt , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org Cc: Leo Yan Subject: [PATCH v1 2/2] perf evlist: Don't run perf in non-root PID namespace when launch workload Date: Sun, 12 Dec 2021 21:47:21 +0800 Message-Id: <20211212134721.1721245-3-leo.yan@linaro.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20211212134721.1721245-1-leo.yan@linaro.org> References: <20211212134721.1721245-1-leo.yan@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In function evlist__prepare_workload(), after perf forks a child process and launches a workload in the created process, it needs to retrieve process and namespace related info via '/proc/$PID/' node. The process folders under 'proc' file system use the PID number from the root PID namespace, when perf tool runs in non-root PID namespace and creates new process for profiled program, this leads to the perf tool wrongly gather process info since it uses PID from non-root namespace to access nodes under '/proc'. Let's see an example: unshare --fork --pid perf record -e cs_etm//u -a -- test_program This command runs perf tool and the profiled program 'test_program' in the non-root PID namespace. When perf tool launches 'test_program', e.g. the forked PID number is 2, perf tool retrieves process info for 'test_program' from the folder '/proc/2'. But '/proc/2' is actually for a kernel thread so perf tool wrongly gather info for 'test_program'. To fix this issue, we don't allow perf tool runs in non-root PID namespace when it launches workload and reports error in this case. This can notify users to run the perf tool in root PID namespace to gather correct info for profiled program. Signed-off-by: Leo Yan --- tools/perf/util/evlist.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c index 5f92319ce258..bdf79a97db66 100644 --- a/tools/perf/util/evlist.c +++ b/tools/perf/util/evlist.c @@ -11,6 +11,7 @@ #include #include "cpumap.h" #include "util/mmap.h" +#include "util/namespaces.h" #include "thread_map.h" #include "target.h" #include "evlist.h" @@ -1364,6 +1365,12 @@ int evlist__prepare_workload(struct evlist *evlist, struct target *target, const int child_ready_pipe[2], go_pipe[2]; char bf; + if (!nsinfo__is_in_root_namespace()) { + pr_err("Perf runs in non-root PID namespace; please run perf tool "); + pr_err("in the root PID namespace for gathering process info.\n"); + return -EPERM; + } + if (pipe(child_ready_pipe) < 0) { perror("failed to create 'ready' pipe"); return -1; -- 2.25.1