From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Mon, 4 Jan 2016 16:55:35 +0000 Subject: [PATCH v2] arm64: Store breakpoint single step state into pstate In-Reply-To: <1450921362-198371-1-git-send-email-wangnan0@huawei.com> References: <1450860731-194418-1-git-send-email-wangnan0@huawei.com> <1450921362-198371-1-git-send-email-wangnan0@huawei.com> Message-ID: <20160104165535.GI1616@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hello, On Thu, Dec 24, 2015 at 01:42:42AM +0000, Wang Nan wrote: > Two 'perf test' fail on arm64: > > # perf test overflow > 17: Test breakpoint overflow signal handler : FAILED! > 18: Test breakpoint overflow sampling : FAILED! > > When breakpoint raises, after perf_bp_event, breakpoint_handler() > temporary disables breakpoint and enables single step. Then in > single_step_handler(), reenable breakpoint. Without doing this > the breakpoint would be triggered again. > > However, if there's a pending signal and it have signal handler, > control would be transfer to signal handler, so single step handler > would be applied to the first instruction of signal handler. After > the handler return, the instruction triggered the breakpoint would be > executed again. At this time the breakpoint is enabled, so the > breakpoint is triggered again. Whilst I appreciate that you're just trying to get those tests passing on arm64, I really don't think its a good idea for us to try and emulate the x86 debug semantics here. This doesn't happen for ptrace, and I think we're likely to break more than we fix if we try to do it for perf too. The problem seems to be that we take the debug exception before the breakpointed instruction has been executed and call perf_bp_event at that moment, so when we single-step the faulting instruction we actually step into the SIGIO handler and end up getting stuck. Your fix doesn't really address this afaict, in that you don't (can't?) handle: * A longjmp out of a signal handler * A watchpoint and a breakpoint that fire on the same instruction * User-controlled single-step from a signal handler that enables a breakpoint explicitly * Nested signals so I'd really rather leave the code as-is. Will From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752221AbcADQzl (ORCPT ); Mon, 4 Jan 2016 11:55:41 -0500 Received: from foss.arm.com ([217.140.101.70]:53882 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751354AbcADQzj (ORCPT ); Mon, 4 Jan 2016 11:55:39 -0500 Date: Mon, 4 Jan 2016 16:55:35 +0000 From: Will Deacon To: Wang Nan Cc: takahiro.akashi@linaro.org, guohanjun@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, pi3orama@163.com, Fengguang Wu , Jiri Olsa Subject: Re: [PATCH v2] arm64: Store breakpoint single step state into pstate Message-ID: <20160104165535.GI1616@arm.com> References: <1450860731-194418-1-git-send-email-wangnan0@huawei.com> <1450921362-198371-1-git-send-email-wangnan0@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1450921362-198371-1-git-send-email-wangnan0@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 Hello, On Thu, Dec 24, 2015 at 01:42:42AM +0000, Wang Nan wrote: > Two 'perf test' fail on arm64: > > # perf test overflow > 17: Test breakpoint overflow signal handler : FAILED! > 18: Test breakpoint overflow sampling : FAILED! > > When breakpoint raises, after perf_bp_event, breakpoint_handler() > temporary disables breakpoint and enables single step. Then in > single_step_handler(), reenable breakpoint. Without doing this > the breakpoint would be triggered again. > > However, if there's a pending signal and it have signal handler, > control would be transfer to signal handler, so single step handler > would be applied to the first instruction of signal handler. After > the handler return, the instruction triggered the breakpoint would be > executed again. At this time the breakpoint is enabled, so the > breakpoint is triggered again. Whilst I appreciate that you're just trying to get those tests passing on arm64, I really don't think its a good idea for us to try and emulate the x86 debug semantics here. This doesn't happen for ptrace, and I think we're likely to break more than we fix if we try to do it for perf too. The problem seems to be that we take the debug exception before the breakpointed instruction has been executed and call perf_bp_event at that moment, so when we single-step the faulting instruction we actually step into the SIGIO handler and end up getting stuck. Your fix doesn't really address this afaict, in that you don't (can't?) handle: * A longjmp out of a signal handler * A watchpoint and a breakpoint that fire on the same instruction * User-controlled single-step from a signal handler that enables a breakpoint explicitly * Nested signals so I'd really rather leave the code as-is. Will