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 X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F1E4C11D24 for ; Fri, 21 Feb 2020 01:53:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1179F24653 for ; Fri, 21 Feb 2020 01:53:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582250008; bh=C8bGcSueOdDkq7N9q0qwpGRWJ4a+Jl56BSvJqo7zewQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=YzuVn6J5XHDOPIbohos7wCt7M5+HvD5c50Zp0lnlk2f6K2lfINZU74ACKKt3UHJEK UlhehI/B4QmWwQBdfEC6PSmav7WBMhLlcXwzVHTBG7cdHQoT7g4tk5XrhLn0HJvrEF q44EO7i01lyFUfzDVuZh+yCTA4H5Y+N0oIVeibhA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729613AbgBUBx1 (ORCPT ); Thu, 20 Feb 2020 20:53:27 -0500 Received: from mail.kernel.org ([198.145.29.99]:57018 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729523AbgBUBx0 (ORCPT ); Thu, 20 Feb 2020 20:53:26 -0500 Received: from quaco.ghostprotocols.net (unknown [179.97.37.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D7A962467A; Fri, 21 Feb 2020 01:53:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582250005; bh=C8bGcSueOdDkq7N9q0qwpGRWJ4a+Jl56BSvJqo7zewQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NEYZOo1eYvJJdTfT1GvvxJFWdicwFnBJZuxEIngTxBOfUE6BMLl5yvJUgOjZShRZV utd61LPZtjexuKqQHDDuHcCLR99FMsXthGXepBFstVHT7GSjIAOWUPM4qxVYtd3s8E CAIaUPEdixr2tvq6myTcvYvlaYPFBnbCcFz0MMa8= From: Arnaldo Carvalho de Melo To: Ingo Molnar , Thomas Gleixner Cc: Jiri Olsa , Namhyung Kim , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Thomas Richter , Masami Hiramatsu , Arnaldo Carvalho de Melo , Heiko Carstens , Sumanth Korikkar , Vasily Gorbik Subject: [PATCH 2/8] perf test: Fix test trace+probe_vfs_getname.sh on s390 Date: Thu, 20 Feb 2020 22:53:04 -0300 Message-Id: <20200221015310.16914-3-acme@kernel.org> X-Mailer: git-send-email 2.21.1 In-Reply-To: <20200221015310.16914-1-acme@kernel.org> References: <20200221015310.16914-1-acme@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Thomas Richter This test places a kprobe to function getname_flags() in the kernel which has the following prototype: struct filename *getname_flags(const char __user *filename, int flags, int *empty) The 'filename' argument points to a filename located in user space memory. Looking at commit 88903c464321c ("tracing/probe: Add ustring type for user-space string") the kprobe should indicate that user space memory is accessed. Output before: [root@m35lp76 perf]# ./perf test 66 67 66: Use vfs_getname probe to get syscall args filenames : FAILED! 67: Check open filename arg using perf trace + vfs_getname: FAILED! [root@m35lp76 perf]# Output after: [root@m35lp76 perf]# ./perf test 66 67 66: Use vfs_getname probe to get syscall args filenames : Ok 67: Check open filename arg using perf trace + vfs_getname: Ok [root@m35lp76 perf]# Comments from Masami Hiramatsu: This bug doesn't happen on x86 or other archs on which user address space and kernel address space is the same. On some arches (ppc64 in this case?) user address space is partially or completely the same as kernel address space. (Yes, they switch the world when running into the kernel) In this case, we need to use different data access functions for each space. That is why I introduced the "ustring" type for kprobe events. As far as I can see, Thomas's patch is sane. Thomas, could you show us your result on your test environment? Comments from Thomas Richter: Test results for s/390 included above. Signed-off-by: Thomas Richter Acked-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Heiko Carstens Cc: Sumanth Korikkar Cc: Vasily Gorbik Link: http://lore.kernel.org/lkml/20200217102111.61137-1-tmricht@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/tests/shell/lib/probe_vfs_getname.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/tests/shell/lib/probe_vfs_getname.sh b/tools/perf/tests/shell/lib/probe_vfs_getname.sh index 7cb99b433888..c2cc42daf924 100644 --- a/tools/perf/tests/shell/lib/probe_vfs_getname.sh +++ b/tools/perf/tests/shell/lib/probe_vfs_getname.sh @@ -14,7 +14,7 @@ add_probe_vfs_getname() { if [ $had_vfs_getname -eq 1 ] ; then line=$(perf probe -L getname_flags 2>&1 | egrep 'result.*=.*filename;' | sed -r 's/[[:space:]]+([[:digit:]]+)[[:space:]]+result->uptr.*/\1/') perf probe -q "vfs_getname=getname_flags:${line} pathname=result->name:string" || \ - perf probe $verbose "vfs_getname=getname_flags:${line} pathname=filename:string" + perf probe $verbose "vfs_getname=getname_flags:${line} pathname=filename:ustring" fi } -- 2.21.1