From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E071C3F6B0 for ; Thu, 4 Aug 2022 09:18:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239099AbiHDJS5 (ORCPT ); Thu, 4 Aug 2022 05:18:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236209AbiHDJSy (ORCPT ); Thu, 4 Aug 2022 05:18:54 -0400 Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD0CC3A481 for ; Thu, 4 Aug 2022 02:18:53 -0700 (PDT) Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-31f443e276fso194831127b3.1 for ; Thu, 04 Aug 2022 02:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sNY7czIwpusO61rJoPeCDEV4Qf2V9wWZoLziIXNiH+s=; b=vzFkIV/rafqwxh8Mr8sBx/JfIM48MDGM+Jt/kvgG9oTjkJlm+sJY5zCkmX9IFhsBai zDJRaeWnM/aot1ZLjJPo/6qILKNWIwYiWSj8c4uSZ4K9kMeLxTc6tX/TDCYfYrdelfik 5Iw5oYsxqaYyARR89wCG3L1R1U9XmGtNYb2X4bffIPZWbVLXsbZ6FkX7TxWMsRnyHGzB W5KRWTwQ/SvKdbBZ3LgfUowTnkIvmBEfyDX7oeiNvKVlQbA3x9n3QGeHSueLV2qxbk7k 8GQnjthxPUwk+sBRSGvxRq8sku96p+BFb3Gjex58qD/lmQCN+2u5YIB3nWbg2wHu9psl 1XUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sNY7czIwpusO61rJoPeCDEV4Qf2V9wWZoLziIXNiH+s=; b=o57otsHQV9mzic0N1eedH0sQs0pM3plAwjBPBWTEU7JaONo5d/jDPaAr62rnAlk2Lq TJu3ezFVJWSqyw/8Lg2Z+k1VY3VFz5bNp+vb132eMZWL89LBxsxl2k07kX5mjF1faNXi hos9F2yRPp/Ub9+nFsFbVi4zs/ZEYAXDnahAYP/FtY//kMhOmBzOIIIyY6eEQopie+dX ORNpdxuHvHmMWgbMbD0R7eW7bUhzPOadHns82lNnSe1NxYGhftbEERB8vwHCs/ebgS1T K+ajCs7Zt3qioSzw4V9oHYKNqb85abk22H6Gtnddt/cuEF0ezKhqJUn/IzsVbAq6noPb f43w== X-Gm-Message-State: ACgBeo3wTJ5o8rvT7CjLREJhffPfQP0yULGy011gW9RrUEOlkUxZc/+r RVI5VS6sxZ+9Q2/0DgA0S1Ff8DR1FV4qgGzQGcMjGQ== X-Google-Smtp-Source: AA6agR4OnbPJ7p4M7PNNQa0wGF0qm0yUOdd9l3yhulo7HfOqSXiut4Tj8KXeNTmFHiIsvGpfGPZr5ysGSBfMQxpAa9Q= X-Received: by 2002:a0d:e853:0:b0:321:c297:c9b2 with SMTP id r80-20020a0de853000000b00321c297c9b2mr852797ywe.493.1659604733056; Thu, 04 Aug 2022 02:18:53 -0700 (PDT) MIME-Version: 1.0 References: <20220511060521.465744-1-sumit.garg@linaro.org> In-Reply-To: From: Sumit Garg Date: Thu, 4 Aug 2022 14:48:41 +0530 Message-ID: Subject: Re: [PATCH v3 0/2] arm64: Fix pending single-step debugging issues To: Doug Anderson Cc: Daniel Thompson , Will Deacon , Wei Li , Catalin Marinas , Mark Rutland , Masami Hiramatsu , Jason Wessel , Marc Zyngier , Linux ARM , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 11 Jul 2022 at 19:21, Sumit Garg wrote: > > On Mon, 11 Jul 2022 at 19:17, Doug Anderson wrote: > > > > Hi, > > > > On Mon, Jul 11, 2022 at 5:44 AM Sumit Garg wrote: > > > > > > > I'll also note that I _think_ I remember that with Wei's series that > > > > the gdb function "call" started working. I tried that here and it > > > > didn't seem so happy. To keep things simple, I created a dummy > > > > function in my kernel that looked like: > > > > > > > > void doug_test(void) > > > > { > > > > pr_info("testing, 1 2 3\n"); > > > > } > > > > > > > > I broke into the debugger by echoing "g" to /proc/sysrq-trigger and > > > > then tried "call doug_test()". I guess my printout actually printed > > > > but it wasn't so happy after that. Seems like it somehow ended up > > > > returning to a bogus address after the call which then caused a crash. > > > > > > > > > > I am able to reproduce this issue on my setup as well. But it doesn't > > > seem to be a regression caused by this patch-set over Wei's series. As > > > I could reproduce this issue with v1 [1] patch-set as well which was > > > just a forward port of pending patches from Wei's series to the latest > > > upstream. > > > > > > Maybe it's a different regression caused by other changes? BTW, do you > > > remember the kernel version you tested with Wei's series applied? > > > > Sorry, I don't remember! :( I can't even be 100% sure that I'm > > remembering correctly that I tested it back in the day, so it's > > possible that it simply never worked... > > Okay, no worries. Let me see if I can come up with a separate fix for this. > After digging deep into GDB call function operations for aarch64, it is certain that function calls simply never worked due to below reasons: 1. On aarch64, GDB call function inserts a breakpoint at the entrypoint of kernel (which is ffffffc008000000 from your dump) as return address from function called. And since it refers to the "_text" symbol which is marked non-executable as the actual text section starts with the "_stext" symbol. I did a following hack that makes it executable: diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index 626ec32873c6..e39ad1a5f5d6 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -700,7 +700,7 @@ static bool arm64_early_this_cpu_has_bti(void) static void __init map_kernel(pgd_t *pgdp) { static struct vm_struct vmlinux_text, vmlinux_rodata, vmlinux_inittext, - vmlinux_initdata, vmlinux_data; + vmlinux_initdata, vmlinux_data, vmlinux_htext; /* * External debuggers may need to write directly to the text @@ -721,6 +721,8 @@ static void __init map_kernel(pgd_t *pgdp) * Only rodata will be remapped with different permissions later on, * all other segments are allowed to use contiguous mappings. */ + map_kernel_segment(pgdp, _text, _stext, text_prot, &vmlinux_htext, 0, + VM_NO_GUARD); map_kernel_segment(pgdp, _stext, _etext, text_prot, &vmlinux_text, 0, VM_NO_GUARD); map_kernel_segment(pgdp, __start_rodata, __inittext_begin, PAGE_KERNEL, 2. For the GDB function "call" to work, GDB inserts a dummy stack frame. But in case of kernel on aarch64, the stack used is common among the exception handler and the kernel threads. So it's not trivial to insert a dummy stack frame and requires rework of exception entry code as it pushes pt_regs onto the stack. -Sumit > > > > > -Doug From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 529C3C19F2B for ; Thu, 4 Aug 2022 09:20:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=VgRurKUKznPbag4fxQr7EyucWI0V8jaqv6tTvjBRBNg=; b=XS0OQdmZxmR08D DFcErRVJb6YDipQiINFt+b3pNVj4Vfj4KUuAOlH2NiVh86tIA2L03I6VIYAM6Zeehs31TMNV0deRJ E85jWa+ecVVkfaN+gql+ZUZfE+oRhut3Z3oIvZlC6PAthlsmTlOKMxnvQTSeglzzvS2mAmPFci7z6 6k8acf1/2vKXTou1tGXHPsMft53l6Rk/nl2k9v19/05JTL74jCKLgb0qLff0Vj9b4SfexJVChl6A6 HWBkdal40kdIWXPRqlneSrOcMe56OZqXraZOHcZRRXbxqsehVq455THeqrPDii4+/qWZ9ehvjasyq PgWQjApzoSytcootXmYg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oJX0Q-004kbI-E8; Thu, 04 Aug 2022 09:19:02 +0000 Received: from mail-yw1-x1136.google.com ([2607:f8b0:4864:20::1136]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oJX0L-004kWp-4c for linux-arm-kernel@lists.infradead.org; Thu, 04 Aug 2022 09:18:58 +0000 Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-3246910dac3so142620987b3.12 for ; Thu, 04 Aug 2022 02:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sNY7czIwpusO61rJoPeCDEV4Qf2V9wWZoLziIXNiH+s=; b=vzFkIV/rafqwxh8Mr8sBx/JfIM48MDGM+Jt/kvgG9oTjkJlm+sJY5zCkmX9IFhsBai zDJRaeWnM/aot1ZLjJPo/6qILKNWIwYiWSj8c4uSZ4K9kMeLxTc6tX/TDCYfYrdelfik 5Iw5oYsxqaYyARR89wCG3L1R1U9XmGtNYb2X4bffIPZWbVLXsbZ6FkX7TxWMsRnyHGzB W5KRWTwQ/SvKdbBZ3LgfUowTnkIvmBEfyDX7oeiNvKVlQbA3x9n3QGeHSueLV2qxbk7k 8GQnjthxPUwk+sBRSGvxRq8sku96p+BFb3Gjex58qD/lmQCN+2u5YIB3nWbg2wHu9psl 1XUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sNY7czIwpusO61rJoPeCDEV4Qf2V9wWZoLziIXNiH+s=; b=zW5Kxk9XfuYJ+JnQ92sX1Tv6OZywiyrbum4OVE15XDfmymIbVBDTddqAlihrZx2Gz4 B4KqvfkDm6q7PoILL6ByoW/D2nIpLhASod+ObBWyLhOq6b9lONGUXP8lj5R5WRYXUwEe /HRTA3oAa9JHh7Io3XaulJxwFtz7NdOxBlXLUFZA9IIftYJy37FVmurmqZOXVLISmQcQ LTagdyuFhddB3YHS5jgyJhUndX6nNILw1es03y+b9Iqqds+qNV4VQB8GCfDp0oaD46bB A0oqFd985ew4nDs7LFi8IQ7eloj45jhRYKQqhuB/q0kHKW79ab6w/G3J7ByhLXWZ2jS7 AqzQ== X-Gm-Message-State: ACgBeo3DXwSH1AN2qfEYe5Rsu/VyMX783Kt8ojyWNUsYGAIt2yzKiK57 eJ3VeccnRxqxtVzreecApui8sG7/NDEwFV665Yfj+Q== X-Google-Smtp-Source: AA6agR4OnbPJ7p4M7PNNQa0wGF0qm0yUOdd9l3yhulo7HfOqSXiut4Tj8KXeNTmFHiIsvGpfGPZr5ysGSBfMQxpAa9Q= X-Received: by 2002:a0d:e853:0:b0:321:c297:c9b2 with SMTP id r80-20020a0de853000000b00321c297c9b2mr852797ywe.493.1659604733056; Thu, 04 Aug 2022 02:18:53 -0700 (PDT) MIME-Version: 1.0 References: <20220511060521.465744-1-sumit.garg@linaro.org> In-Reply-To: From: Sumit Garg Date: Thu, 4 Aug 2022 14:48:41 +0530 Message-ID: Subject: Re: [PATCH v3 0/2] arm64: Fix pending single-step debugging issues To: Doug Anderson Cc: Daniel Thompson , Will Deacon , Wei Li , Catalin Marinas , Mark Rutland , Masami Hiramatsu , Jason Wessel , Marc Zyngier , Linux ARM , LKML X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220804_021857_217495_41DFDA7F X-CRM114-Status: GOOD ( 30.84 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 11 Jul 2022 at 19:21, Sumit Garg wrote: > > On Mon, 11 Jul 2022 at 19:17, Doug Anderson wrote: > > > > Hi, > > > > On Mon, Jul 11, 2022 at 5:44 AM Sumit Garg wrote: > > > > > > > I'll also note that I _think_ I remember that with Wei's series that > > > > the gdb function "call" started working. I tried that here and it > > > > didn't seem so happy. To keep things simple, I created a dummy > > > > function in my kernel that looked like: > > > > > > > > void doug_test(void) > > > > { > > > > pr_info("testing, 1 2 3\n"); > > > > } > > > > > > > > I broke into the debugger by echoing "g" to /proc/sysrq-trigger and > > > > then tried "call doug_test()". I guess my printout actually printed > > > > but it wasn't so happy after that. Seems like it somehow ended up > > > > returning to a bogus address after the call which then caused a crash. > > > > > > > > > > I am able to reproduce this issue on my setup as well. But it doesn't > > > seem to be a regression caused by this patch-set over Wei's series. As > > > I could reproduce this issue with v1 [1] patch-set as well which was > > > just a forward port of pending patches from Wei's series to the latest > > > upstream. > > > > > > Maybe it's a different regression caused by other changes? BTW, do you > > > remember the kernel version you tested with Wei's series applied? > > > > Sorry, I don't remember! :( I can't even be 100% sure that I'm > > remembering correctly that I tested it back in the day, so it's > > possible that it simply never worked... > > Okay, no worries. Let me see if I can come up with a separate fix for this. > After digging deep into GDB call function operations for aarch64, it is certain that function calls simply never worked due to below reasons: 1. On aarch64, GDB call function inserts a breakpoint at the entrypoint of kernel (which is ffffffc008000000 from your dump) as return address from function called. And since it refers to the "_text" symbol which is marked non-executable as the actual text section starts with the "_stext" symbol. I did a following hack that makes it executable: diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index 626ec32873c6..e39ad1a5f5d6 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -700,7 +700,7 @@ static bool arm64_early_this_cpu_has_bti(void) static void __init map_kernel(pgd_t *pgdp) { static struct vm_struct vmlinux_text, vmlinux_rodata, vmlinux_inittext, - vmlinux_initdata, vmlinux_data; + vmlinux_initdata, vmlinux_data, vmlinux_htext; /* * External debuggers may need to write directly to the text @@ -721,6 +721,8 @@ static void __init map_kernel(pgd_t *pgdp) * Only rodata will be remapped with different permissions later on, * all other segments are allowed to use contiguous mappings. */ + map_kernel_segment(pgdp, _text, _stext, text_prot, &vmlinux_htext, 0, + VM_NO_GUARD); map_kernel_segment(pgdp, _stext, _etext, text_prot, &vmlinux_text, 0, VM_NO_GUARD); map_kernel_segment(pgdp, __start_rodata, __inittext_begin, PAGE_KERNEL, 2. For the GDB function "call" to work, GDB inserts a dummy stack frame. But in case of kernel on aarch64, the stack used is common among the exception handler and the kernel threads. So it's not trivial to insert a dummy stack frame and requires rework of exception entry code as it pushes pt_regs onto the stack. -Sumit > > > > > -Doug _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel