From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753542AbbLCULG (ORCPT ); Thu, 3 Dec 2015 15:11:06 -0500 Received: from flmx07.ccur.com ([12.220.59.12]:22653 "EHLO flmx07.ccur.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753518AbbLCULD (ORCPT ); Thu, 3 Dec 2015 15:11:03 -0500 X-Greylist: delayed 330 seconds by postgrey-1.27 at vger.kernel.org; Thu, 03 Dec 2015 15:11:03 EST To: Will Deacon CC: From: John Blackwood Subject: [PATCH] ARM64: Clear out any singlestep state on a ptrace detach operation Message-ID: <5660A08B.6030204@ccur.com> Date: Thu, 3 Dec 2015 14:05:31 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Will, I have a patch for a ptrace(2) issue that we encountered on arm64 kernels. If a debugger singlesteps a ptraced task, and then does a ptrace(2) PTRACE_DETACH command, the task will not resume successfully. It seems that clearing out the singlestep state, as something like a ptrace(2) PTRACE_CONT does, gets this working. Thank you for your time and considerations. ----- ----- arm64: Clear out any singlestep state on a ptrace detach operation. Make sure to clear out any ptrace singlestep state when a ptrace(2) PTRACE_DETACH call is made on arm64 systems. Otherwise, the previously ptraced task will die off with a SIGTRAP signal if the debugger just previously singlestepped the ptraced task. Signed-off-by: John Blackwood Index: b/arch/arm64/kernel/ptrace.c =================================================================== --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -58,6 +58,7 @@ */ void ptrace_disable(struct task_struct *child) { + user_disable_single_step(child); } #ifdef CONFIG_HAVE_HW_BREAKPOINT