From patchwork Thu Aug 10 02:52:45 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ding Tianhong X-Patchwork-Id: 109775 Delivered-To: patch@linaro.org Received: by 10.140.95.78 with SMTP id h72csp1737457qge; Wed, 9 Aug 2017 19:53:38 -0700 (PDT) X-Received: by 10.99.96.150 with SMTP id u144mr9882125pgb.338.1502333618857; Wed, 09 Aug 2017 19:53:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1502333618; cv=none; d=google.com; s=arc-20160816; b=leXPykp9TnqYFHDKc1/qtZIm3spUNR3AVPnbB0iz6nV1j+VWKBwPtO5Ry8E8CVNpku lDrEIzyYzHzw8Z94SVECfCdpD/mL+9kAzywuoGE21+Owte5KmUBVpIp6KplTrvVa6OJe +qr/3kjhrttuLv7Cc+RZn/9cbod601Joq+o23J9wqCtkIug19NBsV/xuKEvT8O8gBx41 FMNSpEJr7Y2XBtkgvUKbLcxTNHwfDsv7MqubVmqXRm7hl7LxhMa8q4j0Ogr6N1gDLqQM +CmvkClfFnOcn9Bzh3mWpLCVnG8yN7NFdBydWqOI/AtX1oF0e6zRTk1HEVLf8FOZSwMc +FKQ== 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 :user-agent:date:message-id:to:subject:from :arc-authentication-results; bh=R1JcqilQRAVZgSB/fVsXs9m/YGCTFkaCXh4yAvqB6bE=; b=x+LhAW87NMpzmU4NHgtlLXeNsDupLeE4NVXEE02FzBg2IL2CbSnbQh4yFzaJzuhGSS DzPYyq9s6vJ+4WDjsnKasBjgNoaoFHyUI8Ezzxi1S+NwEwohwqdhqA2GKNBid55fAZOF Y+VceeA/uzaLCt+TQlru3aBUSTsW4HDxXUjKdSc9y5x0xugQzdCmsIPqt8S7tfm6GqdV ktldZ1za+liGWBRfGcx/sDE45KuyLJLgpdZRw+sVaNiwtT+bCIOl3F7tvrL2MSWXNalU oVYB6QApYGN23a5TvV6pc0ho6F9Q45DVIZBwl+8cUFW5Y40Ep14v1YeeuzOBrlLlaNsG Dv3w== 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 z19si3329786pgj.546.2017.08.09.19.53.38; Wed, 09 Aug 2017 19:53:38 -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 S1752372AbdHJCxf (ORCPT + 25 others); Wed, 9 Aug 2017 22:53:35 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:2604 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752094AbdHJCxe (ORCPT ); Wed, 9 Aug 2017 22:53:34 -0400 Received: from 172.30.72.60 (EHLO DGGEMS407-HUB.china.huawei.com) ([172.30.72.60]) by dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id DEX44823; Thu, 10 Aug 2017 10:52:59 +0800 (CST) Received: from [127.0.0.1] (10.177.23.32) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.301.0; Thu, 10 Aug 2017 10:52:51 +0800 From: Ding Tianhong Subject: [PATCH v2] arm64: arch_timer: avoid infinite recursion when ftrace is enabled To: Mark Rutland , Marc Zyngier , Catalin Marinas , Will Deacon , LinuxArm , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Message-ID: Date: Thu, 10 Aug 2017 10:52:45 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 X-Originating-IP: [10.177.23.32] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.598BCA8B.0050, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5188f2b76470b5cf1a6c2042ade20bba Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On platforms with an arch timer erratum workaround, it's possible for arch_timer_reg_read_stable() to recurse into itself when certain tracing options are enabled, leading to stack overflows and related problems. For example, when PREEMPT_TRACER and FUNCTION_GRAPH_TRACER are selected, it's possible to trigger this with: $ mount -t debugfs nodev /sys/kernel/debug/ $ echo function_graph > /sys/kernel/debug/tracing/current_tracer The problem is that in such cases, preempt_disable() instrumentation attempts to acquire a timestamp via trace_clock(), resulting in a call back to arch_timer_reg_read_stable(), and hence recursion. This patch changes arch_timer_reg_read_stable() to use preempt_{disable,enable}_notrace(), which avoids this. This problem is similar to the fixed by upstream commit 96b3d28bf4 ("sched/clock: Prevent tracing recursion in sched_clock_cpu()"). Fixes: 6acc71ccac71 ("arm64: arch_timer: Allows a CPU-specific erratum to only affect a subset of CPUs") Signed-off-by: Ding Tianhong Acked-by: Mark Rutland Acked-by: Marc Zyngier --- arch/arm64/include/asm/arch_timer.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 1.9.0 diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h index 74d08e4..67bb7a4 100644 --- a/arch/arm64/include/asm/arch_timer.h +++ b/arch/arm64/include/asm/arch_timer.h @@ -65,13 +65,13 @@ struct arch_timer_erratum_workaround { u64 _val; \ if (needs_unstable_timer_counter_workaround()) { \ const struct arch_timer_erratum_workaround *wa; \ - preempt_disable(); \ + preempt_disable_notrace(); \ wa = __this_cpu_read(timer_unstable_counter_workaround); \ if (wa && wa->read_##reg) \ _val = wa->read_##reg(); \ else \ _val = read_sysreg(reg); \ - preempt_enable(); \ + preempt_enable_notrace(); \ } else { \ _val = read_sysreg(reg); \ } \