From patchwork Mon Oct 21 13:38:19 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnaldo Carvalho de Melo X-Patchwork-Id: 177088 Delivered-To: patch@linaro.org Received: by 2002:a92:409a:0:0:0:0:0 with SMTP id d26csp3439025ill; Mon, 21 Oct 2019 06:43:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqxZK3dqoFrKwpUYN//Dymj+HVYEVbYoScqKBXJekqkxxx7+kTlIfrJrnQB1jMpFh08jj2ER X-Received: by 2002:a17:906:2d49:: with SMTP id e9mr21987197eji.240.1571665268234; Mon, 21 Oct 2019 06:41:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571665268; cv=none; d=google.com; s=arc-20160816; b=yzTTpRiN0vfAxzgZC3JERHlehLHCaEmcWyff8FOu79eBdH/EU2yU+vpn7JsY5voTwA ymuyGUtciPQxIMe26JdhddY3HKxOhJgw3uSVzH4yuTA/4hEphK/MUZQa8ulY4DmrCIG0 3XN3MHZJZ3dSbWnUvsyxE+WhOFhLPuwMh1S2wgqAFGMrNP6NVJCazpEK0uWzSsTSKrvv GEOsZQXNPf93sIO8OJ+6DcPBBQkszT+uUdoIlh8AQKl6dwCiVyQf/LV/o7O2a9P/28xO /23m34YnC3PbCR6ZKx8SG9AcaWezy0EKGDzfhEdigW1GeQEZBzmtlzaUBWUcCO5Cixxk 2gEg== 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:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=F53qv+AoWgm8s1YI0hkli4VRKchnZ9wCqDT3B7fpeng=; b=BAyN+VxgUjHbneQADqLD2o7SXuNtpjquK2zbWKvEflf5nOVkU4i4brmeprvqHuaCGp Rxu7fBCpdfjUdklIwYhC6MwLI0+z3OL5kGyk8Q1aW7T9pJvis/WkmWqoKKSdKGiqakhE iEAPJyixsAXr69IJ7fX3Y8Vbimg9CFXeGpGkeG5Hm8MAWdaa+QEPnegCvkloN7K1ZQJA vbA/zUMAtRN2ggIYwF4wlTy7cvjsnXFNLkiNCLNMCbFaAU1YecIdFZlJVu7Gp5Y6gFuc 4P6N9yrfWYYflwh1yLGQKEVKA/qrrR2GEPfoz3hniR5hZuzspXBwuFPiFOkxH6pCwbZ7 mgag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=clFRhUYj; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z33si2306306edz.114.2019.10.21.06.41.07; Mon, 21 Oct 2019 06:41:08 -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; dkim=pass header.i=@kernel.org header.s=default header.b=clFRhUYj; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729617AbfJUNlF (ORCPT + 26 others); Mon, 21 Oct 2019 09:41:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:42910 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729001AbfJUNlA (ORCPT ); Mon, 21 Oct 2019 09:41:00 -0400 Received: from quaco.ghostprotocols.net (unknown [179.97.35.50]) (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 2240D21783; Mon, 21 Oct 2019 13:40:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1571665259; bh=/yMYdILkEZpciGS3rhWRI3Vk6HWst0iqEjJYsYFZioc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=clFRhUYjybmHd9H6I+nvh3jXC0nFctKgSBRvLrTS7vt5LVbrQ923tHok2KYQxluaQ OCMBvnSiwCNR35NbIDM64C53k6Chi/f319q0fVGDcts2rc7z3z+4IzyGROPGtnyNif SFfISwlJLvtTPNYbvUpxTvf567w37q7+0he7N3bA= 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, Leo Yan , Adrian Hunter , Alexander Shishkin , Brajeswar Ghosh , Florian Fainelli , Jiri Olsa , Mark Rutland , Michael Petlan , Peter Zijlstra , Song Liu , Souptick Joarder , Will Deacon , Arnaldo Carvalho de Melo Subject: [PATCH 42/57] perf tests: Disable bp_signal testing for arm64 Date: Mon, 21 Oct 2019 10:38:19 -0300 Message-Id: <20191021133834.25998-43-acme@kernel.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20191021133834.25998-1-acme@kernel.org> References: <20191021133834.25998-1-acme@kernel.org> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Leo Yan 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(-) -- 2.21.0 diff --git a/tools/perf/tests/bp_signal.c b/tools/perf/tests/bp_signal.c index c1c2c13de254..166f411568a5 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;