Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp4921060ybg; Mon, 21 Oct 2019 17:06:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqwlTMou6NiZQ0kIgr2bg4F5oTRJ9AdPhib/eTiTvfeJzfcTjMfWj95pwm5DrL0lapDvj6re X-Received: by 2002:a17:906:e090:: with SMTP id gh16mr25025719ejb.56.1571702813878; Mon, 21 Oct 2019 17:06:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571702813; cv=none; d=google.com; s=arc-20160816; b=LHTn3+a5HZNR88ix4myGYyQLUYZE3BxTIT2MdPAHWLdhvuD5ZN0bXHA5aB6EOScBqH zHv6yki4spJAdbqLhlXIjeC5+6Tk0LuzX/BPCSIGUnzAy4SJ2uK3eyHWE7ggSuT6yYoA TBQSHZHbI1wwDZpyKtE0v15I3mFqmFhWTQY1yQNcPEqizxc8TTdqkWsQhtXeSVWPZeSo R+NHJvn+uqDaDEAgBDwgEF8JsB23vaBIv837XA5sqELF4Ky5ZzUr8NtjSSqNDdhQ3VB9 jpr7yXh/5m5BLyx/GmUnKv94UUxUqXCayngwpU+YRN8MDIb+bPXTZ+aOnHWgu/cPQrSQ gvMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :robot-unsubscribe:robot-id:message-id:mime-version:references :in-reply-to:cc:subject:to:reply-to:from:date; bh=9Cr3PAWxTY4Gyoi1YifdAw7OdrcCPReiQVkEPhEqPa8=; b=za6DqTyvReszrrqXVTGQB1YCFk8us2Nzf0M9LKAOb8nBit+fBwxiuI4wkDWG78I8C6 RoqTMDoffcuXoKCAGxEL/9MGygOjMeqxVK81BHB53WmNOhcShHksL3E9QHBlo/n5Wr2o 7YQoVAbpSmZ6LV7pxShPEBExW1231wiOcqirKI6p0j0SXki0nHjHxFe1OroeysKmfUln vrvkDKRlr74DAowa9I3c/woV4JT4Wj7Ej9vq4GzfEd/hO4wAFlklOBk79Qu+AAgbnu8/ F4ywiZS3I5X7p6wyIqAdgMq/+kRPpMZSTn6UZ9GAjFX3Ob9dAe3NJs+rENWCqv/6dT6D izhA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id hk1si9879307ejb.408.2019.10.21.17.06.29; Mon, 21 Oct 2019 17:06:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387612AbfJVAFQ (ORCPT + 99 others); Mon, 21 Oct 2019 20:05:16 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:38895 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387553AbfJVAFI (ORCPT ); Mon, 21 Oct 2019 20:05:08 -0400 Received: from [5.158.153.53] (helo=tip-bot2.lab.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iMgwx-0003v4-D0; Tue, 22 Oct 2019 01:18:55 +0200 Received: from [127.0.1.1] (localhost [IPv6:::1]) by tip-bot2.lab.linutronix.de (Postfix) with ESMTP id 928781C03AB; Tue, 22 Oct 2019 01:18:54 +0200 (CEST) Date: Mon, 21 Oct 2019 23:18:54 -0000 From: "tip-bot2 for Leo Yan" Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: perf/core] perf tests: Disable bp_signal testing for arm64 Cc: Leo Yan , Adrian Hunter , Alexander Shishkin , Brajeswar Ghosh , Florian Fainelli , Jiri Olsa , Mark Rutland , Michael Petlan , Namhyung Kim , Peter Zijlstra , Song Liu , Souptick Joarder , Will Deacon , Arnaldo Carvalho de Melo , Ingo Molnar , Borislav Petkov , linux-kernel@vger.kernel.org In-Reply-To: <20191018085531.6348-3-leo.yan@linaro.org> References: <20191018085531.6348-3-leo.yan@linaro.org> MIME-Version: 1.0 Message-ID: <157169993406.29376.12473771029179755767.tip-bot2@tip-bot2> X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the perf/core branch of tip: Commit-ID: 6a5f3d94cb69a185b921cb92c39888dc31009acb Gitweb: https://git.kernel.org/tip/6a5f3d94cb69a185b921cb92c39888dc31009acb Author: Leo Yan AuthorDate: Fri, 18 Oct 2019 16:55:31 +08:00 Committer: Arnaldo Carvalho de Melo CommitterDate: Sat, 19 Oct 2019 15:35:01 -03:00 perf tests: Disable bp_signal testing for arm64 As there are several discussions for enabling perf breakpoint signal testing on arm64 platform: arm64 needs to rely on single-step to execute the breakpointed instruction and then reinstall the breakpoint exception handler. But if we hook the breakpoint with a signal, the signal handler will do the stepping rather than the breakpointed instruction, this causes infinite loops as below: Kernel space | Userspace ---------------------------------|-------------------------------- | __test_function() -> hit | breakpoint breakpoint_handler() | `-> user_enable_single_step() | do_signal() | | sig_handler() -> Step one | instruction and | trap to kernel single_step_handler() | `-> reinstall_suspended_bps() | | __test_function() -> hit | breakpoint again and | repeat up flow infinitely As Will Deacon mentioned [1]: "that we require the overflow handler to do the stepping on arm/arm64, which is relied upon by GDB/ptrace. The hw_breakpoint code is a complete disaster so my preference would be to rip out the perf part and just implement something directly in ptrace, but it's a pretty horrible job". Though Will commented this on arm architecture, but the comment also can apply on arm64 architecture. For complete information, I searched online and found a few years back, Wang Nan sent one patch 'arm64: Store breakpoint single step state into pstate' [2]; the patch tried to resolve this issue by avoiding single stepping in signal handler and defer to enable the signal stepping when return to __test_function(). The fixing was not merged due to the concern for missing to handle different usage cases. Based on the info, the most feasible way is to skip Perf breakpoint signal testing for arm64 and this could avoid the duplicate investigation efforts when people see the failure. This patch skips this case on arm64 platform, which is same with arm architecture. [1] https://lkml.org/lkml/2018/11/15/205 [2] https://lkml.org/lkml/2015/12/23/477 Signed-off-by: Leo Yan Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Brajeswar Ghosh Cc: Florian Fainelli Cc: Jiri Olsa Cc: Mark Rutland Cc: Michael Petlan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Cc: Souptick Joarder Cc: Will Deacon Link: http://lore.kernel.org/lkml/20191018085531.6348-3-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/tests/bp_signal.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/tools/perf/tests/bp_signal.c b/tools/perf/tests/bp_signal.c index c1c2c13..166f411 100644 --- a/tools/perf/tests/bp_signal.c +++ b/tools/perf/tests/bp_signal.c @@ -49,14 +49,6 @@ asm ( "__test_function:\n" "incq (%rdi)\n" "ret\n"); -#elif defined (__aarch64__) -extern void __test_function(volatile long *ptr); -asm ( - ".globl __test_function\n" - "__test_function:\n" - "str x30, [x0]\n" - "ret\n"); - #else static void __test_function(volatile long *ptr) { @@ -302,10 +294,15 @@ bool test__bp_signal_is_supported(void) * stepping into the SIGIO handler and getting stuck on the * breakpointed instruction. * + * Since arm64 has the same issue with arm for the single-step + * handling, this case also gets suck on the breakpointed + * instruction. + * * Just disable the test for these architectures until these * issues are resolved. */ -#if defined(__powerpc__) || defined(__s390x__) || defined(__arm__) +#if defined(__powerpc__) || defined(__s390x__) || defined(__arm__) || \ + defined(__aarch64__) return false; #else return true;