From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758088AbcCCPBQ (ORCPT ); Thu, 3 Mar 2016 10:01:16 -0500 Received: from foss.arm.com ([217.140.101.70]:37728 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757739AbcCCPBO (ORCPT ); Thu, 3 Mar 2016 10:01:14 -0500 Date: Thu, 3 Mar 2016 15:01:25 +0000 From: Will Deacon To: Hekuang Cc: peterz@infradead.org, mingo@redhat.com, acme@kernel.org, alexander.shishkin@linux.intel.com, adrian.hunter@intel.com, jolsa@kernel.org, linux-kernel@vger.kernel.org, wangnan0@huawei.com, pi3orama@163.com Subject: Re: [BUG ARM64/perf] Perf record on hardware breakpoint causes application to hang Message-ID: <20160303150125.GB16061@arm.com> References: <56D83771.2090101@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56D83771.2090101@huawei.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 03, 2016 at 09:09:05PM +0800, Hekuang wrote: > This problem can be reproduced as follows: > > We know cat /proc/version will read the memory of symbol > linux_proc_banner, then we make a hardware memory access > breakpoint on that address. > > on terminal 1: > > $ perf record -e mem:0x$(cat /proc/kallsyms|grep linux_proc_banner|cut -d > " " -f 1):rw --no-buffer -a > > on terminal 2: > > $ cat /proc/version > > Then our 'cat' process on terminal 2 will be hanged, until we press > '^C' to stop perf from recording events. > > The sample numbers recorded by perf is extraordinary too: > > [ perf record: Captured and wrote 0.879 MB perf.data (22691 samples) ] > > The right result can be produced by removing the 'no-buffer' > argument in perf command line, and the result should be like > this: > > $ perf record -e mem:0x$(cat /proc/kallsyms|grep linux_proc_ > banner|cut -d " " -f 1):rw -a > ^C > [ perf record: Woken up 1 times to write data ] > [ perf record: Captured and wrote 0.013 MB perf.data (10 samples) ] > > Report this bug to you and hope for answers. This sounds like a kernel-space equivalent to the issue reported here: http://lkml.kernel.org/r/569CCEDA.6040103@huawei.com The problem is that we configure a single-step to step the watchpoint and then re-arm it on completion, but because you have buffering disabled, we *always* step into an interrupt thanks to the irq work that is queued by perf to unblock the event fd being polled. We then re-arm the watchpoint and take it immediately on return from the irq handler. Rinse, repeat. We could consider re-enabling interrupts briefly on the debug exception return path, but then we open ourselves up to black spots in the kernel that cannot be debugged. Will