From nobody Wed Sep 17 21:13:20 2025 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 9CC3EC4332F for ; Thu, 15 Dec 2022 14:29:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229904AbiLOO31 (ORCPT ); Thu, 15 Dec 2022 09:29:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229844AbiLOO3Y (ORCPT ); Thu, 15 Dec 2022 09:29:24 -0500 Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C05F125F2 for ; Thu, 15 Dec 2022 06:29:22 -0800 (PST) Received: by mail-pj1-x1036.google.com with SMTP id 3-20020a17090a098300b00219041dcbe9so2833852pjo.3 for ; Thu, 15 Dec 2022 06:29:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=01a2UV5FsPpOUVUYf2R+k+b8Dh0cH0M3wFlrMUvhruw=; b=HqUCLpNQ4nZIY3dP3D3DeWny5wH83I40YR+GanSSNBRAdmWYA6Auprhi94xLnHVRVn IpyiPDX0w3v1al7y1sa3Wl12jQl2T4deTeZWF94P/3ojQhTfuyjRlLOD6I5/NLpJL0H2 6kwyB3Gvovd8EqEfdJUknFfERUe7t3NtWFLEI+n5NielFJjfpoBn61HfitkLaV/p6dqK vDEd278TQv9u+wqxp3VNp5eUXKlaOHvqnQE31XHxNBSzTyygOlB11vjuTTUdLvIW7Pjv PgTXb7djiM10JmiwNbgmgCzjFDtmr/4MY96LJ5HY3t9EG7Cs5ht4Gm3gQFjr7L3dFbGx UItw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=01a2UV5FsPpOUVUYf2R+k+b8Dh0cH0M3wFlrMUvhruw=; b=0lLbJd3OzvMZT4bC0AjDSothwgwRVb0DKcD+EwusnOlFiPdlRN4ey5UltUAhsPRBV8 2Uq3iy5YNQ5nEH7gryErt7Sg63g7Jzm85QaSdgR6NccTxsIK+dRZtQDn9D2wEu4nrF2Y rJBwb8zfbTpRzZ0JAr5pD6EqFvTIvJoml/+we5f16azhD4h+303SeyOxrka70Lq3PoRm HWM4pQyLPsPbWyXT+V+/um+gwD5CCIxEZ/ljL5OWyPVdlMGynwKjU50S4jR5zDJ8fj9c NYLwfoySXy9j1JSWYUB3h0C8/pEF8iSeCttF6crWi4qCLuyoNCUFiqxr1q5+NZ2fwjP6 Tu+g== X-Gm-Message-State: ANoB5pnTLbh2YmL7KjoPlXizZjwFW0Y4aV/0jMD2FGENE4aNDuOUmyL1 DC7dPvADKQvOPRpZEeEX0QjR3w== X-Google-Smtp-Source: AA0mqf7jFS4uGcfnthwZ1zlzzH60cSbqUyCuf8d8mJjKAz8olDA+3XLE/2sQ74av8ehBOHBcQE3qZw== X-Received: by 2002:a17:902:cf12:b0:186:a5a7:cc4e with SMTP id i18-20020a170902cf1200b00186a5a7cc4emr33472597plg.17.1671114562277; Thu, 15 Dec 2022 06:29:22 -0800 (PST) Received: from sumit-X1.. ([223.178.208.45]) by smtp.gmail.com with ESMTPSA id z1-20020a170902d54100b0017f5ad327casm3922010plf.103.2022.12.15.06.29.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Dec 2022 06:29:22 -0800 (PST) From: Sumit Garg To: will@kernel.org, catalin.marinas@arm.com, daniel.thompson@linaro.org, dianders@chromium.org Cc: liwei391@huawei.com, mark.rutland@arm.com, mhiramat@kernel.org, maz@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Sumit Garg Subject: [PATCH v4 1/2] arm64: entry: Skip single stepping into interrupt handlers Date: Thu, 15 Dec 2022 19:59:02 +0530 Message-Id: <20221215142903.2624142-2-sumit.garg@linaro.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221215142903.2624142-1-sumit.garg@linaro.org> References: <20221215142903.2624142-1-sumit.garg@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Currently on systems where the timer interrupt (or any other fast-at-human-scale periodic interrupt) is active then it is impossible to step any code with interrupts unlocked because we will always end up stepping into the timer interrupt instead of stepping the user code. The common user's goal while single stepping is that when they step then the system will stop at PC+4 or PC+I for a branch that gets taken relative to the instruction they are stepping. So, fix broken single step implementation via skipping single stepping into interrupt handlers. The methodology is when we receive an interrupt from EL1, check if we are single stepping (pstate.SS). If yes then we save MDSCR_EL1.SS and clear the register bit if it was set. Then unmask only D and leave I set. On return from the interrupt, set D and restore MDSCR_EL1.SS. Along with this skip reschedule if we were stepping. Suggested-by: Will Deacon Signed-off-by: Sumit Garg Tested-by: Douglas Anderson --- arch/arm64/kernel/entry-common.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-com= mon.c index cce1167199e3..53bcb1902f2f 100644 --- a/arch/arm64/kernel/entry-common.c +++ b/arch/arm64/kernel/entry-common.c @@ -471,19 +471,35 @@ static __always_inline void __el1_irq(struct pt_regs = *regs, do_interrupt_handler(regs, handler); irq_exit_rcu(); =20 - arm64_preempt_schedule_irq(); + /* Don't reschedule in case we are single stepping */ + if (!(regs->pstate & DBG_SPSR_SS)) + arm64_preempt_schedule_irq(); =20 exit_to_kernel_mode(regs); } + static void noinstr el1_interrupt(struct pt_regs *regs, void (*handler)(struct pt_regs *)) { + unsigned long reg; + + /* Disable single stepping within interrupt handler */ + if (regs->pstate & DBG_SPSR_SS) { + reg =3D read_sysreg(mdscr_el1); + write_sysreg(reg & ~DBG_MDSCR_SS, mdscr_el1); + } + write_sysreg(DAIF_PROCCTX_NOIRQ, daif); =20 if (IS_ENABLED(CONFIG_ARM64_PSEUDO_NMI) && !interrupts_enabled(regs)) __el1_pnmi(regs, handler); else __el1_irq(regs, handler); + + if (regs->pstate & DBG_SPSR_SS) { + write_sysreg(DAIF_PROCCTX_NOIRQ | PSR_D_BIT, daif); + write_sysreg(reg, mdscr_el1); + } } =20 asmlinkage void noinstr el1h_64_irq_handler(struct pt_regs *regs) --=20 2.34.1 From nobody Wed Sep 17 21:13:20 2025 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 0115AC4332F for ; Thu, 15 Dec 2022 14:29:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229939AbiLOO3g (ORCPT ); Thu, 15 Dec 2022 09:29:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48604 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229844AbiLOO31 (ORCPT ); Thu, 15 Dec 2022 09:29:27 -0500 Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C26ED2CE1B for ; Thu, 15 Dec 2022 06:29:26 -0800 (PST) Received: by mail-pj1-x102f.google.com with SMTP id t11-20020a17090a024b00b0021932afece4so2884534pje.5 for ; Thu, 15 Dec 2022 06:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=FuxPSSo3Y0HNcsTRiv4LvjgP5Z2vwZbV6xJtY/KrG9Q=; b=GH+o3xGpbeSkSiHU4ZhFMZ9jkmwSgjEShmS+hkyC7LNuC+FLDPkFdCt39W2pFj3AEq 3As93RhfetUr/a7+HyILd1yr1jzNA4jL3g65bSUssPV3DXNsyRiz7MB4Q1IZMNyHQdX0 KdKsXm+wpuXZumoARgb0dOpHO6JxWQXv3nabufiTcvvLq6C/KV29jIjx6SzomLlD3CiL cdoIvLW6MjHKI32o3jL/M6+DbJaMmhAHE3iNhv8LQxF0tqxqQJjUq/W3D0jzhC0oKL1F tjpZFM6Dv21s0Dp9a6xoJGxJmlCzbNMtmDDN3LEC4KyS+J3XtdDbTB03jQdaw5kLlIce EKjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FuxPSSo3Y0HNcsTRiv4LvjgP5Z2vwZbV6xJtY/KrG9Q=; b=2YcjGme5bEdqa0NkgrMRS7FEf5Xz9F4Q3GjsTTawiopblKITzAs3dlx4MyobPWQjo+ W19NMJUYySHK9rRCu+HQQ25ZQQy61ABsqCj4NClF+mpLogBhrVxxLLDaT+1M5UZEhfwb aR3FFaXTDwkd/+a5L4ViwUyv9s/0e43ooHdELAasL/irMHQ1D+HhdaIM+vLCDG0DeDQz nby7rZ6LrbQ0LoGgXghRlMtnzzZPf5x94PcTOxNIQ0wtZhj/pJ++DsCVoB+FH+JzTkh0 pG3wFYrgeKBVRDRqxcD8b2+BsjUlGEWh+jxV0yLHl+Z6md+iHoFqTp0HUA0qE3UtPyzH wiJQ== X-Gm-Message-State: ANoB5pkJLYnqkDVYLXlr1dalQs3ejywDHyODcvtLlawfnUFZ7lgXXyOO JlkZ0u7nCxdISDL+LG9V4iIY2Q== X-Google-Smtp-Source: AA0mqf6Fe2RSsBxw7IoI8CLHsSgyH2bi7UGfEUMoabxqwYlOQ8jx9uJ48AQ0FQtFljyOfs1EiF8dQA== X-Received: by 2002:a17:903:251:b0:189:7891:574d with SMTP id j17-20020a170903025100b001897891574dmr32757233plh.47.1671114566259; Thu, 15 Dec 2022 06:29:26 -0800 (PST) Received: from sumit-X1.. ([223.178.208.45]) by smtp.gmail.com with ESMTPSA id z1-20020a170902d54100b0017f5ad327casm3922010plf.103.2022.12.15.06.29.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Dec 2022 06:29:25 -0800 (PST) From: Sumit Garg To: will@kernel.org, catalin.marinas@arm.com, daniel.thompson@linaro.org, dianders@chromium.org Cc: liwei391@huawei.com, mark.rutland@arm.com, mhiramat@kernel.org, maz@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Sumit Garg Subject: [PATCH v4 2/2] arm64: kgdb: Set PSTATE.SS to 1 to re-enable single-step Date: Thu, 15 Dec 2022 19:59:03 +0530 Message-Id: <20221215142903.2624142-3-sumit.garg@linaro.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221215142903.2624142-1-sumit.garg@linaro.org> References: <20221215142903.2624142-1-sumit.garg@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Currently only the first attempt to single-step has any effect. After that all further stepping remains "stuck" at the same program counter value. Refer to the ARM Architecture Reference Manual (ARM DDI 0487E.a) D2.12, PSTATE.SS=3D1 should be set at each step before transferring the PE to the 'Active-not-pending' state. The problem here is PSTATE.SS=3D1 is not set since the second single-step. After the first single-step, the PE transferes to the 'Inactive' state, with PSTATE.SS=3D0 and MDSCR.SS=3D1, thus PSTATE.SS won't be set to 1 due to kernel_active_single_step()=3Dtrue. Then the PE transferes to the 'Active-pending' state when ERET and returns to the debugger by step exception. Before this patch: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Entering kdb (current=3D0xffff3376039f0000, pid 1) on processor 0 due to Ke= yboard Entry [0]kdb> [0]kdb> [0]kdb> bp write_sysrq_trigger Instruction(i) BP #0 at 0xffffa45c13d09290 (write_sysrq_trigger) is enabled addr at ffffa45c13d09290, hardtype=3D0 installed=3D0 [0]kdb> go $ echo h > /proc/sysrq-trigger Entering kdb (current=3D0xffff4f7e453f8000, pid 175) on processor 1 due to = Breakpoint @ 0xffffad651a309290 [1]kdb> ss Entering kdb (current=3D0xffff4f7e453f8000, pid 175) on processor 1 due to = SS trap @ 0xffffad651a309294 [1]kdb> ss Entering kdb (current=3D0xffff4f7e453f8000, pid 175) on processor 1 due to = SS trap @ 0xffffad651a309294 [1]kdb> After this patch: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Entering kdb (current=3D0xffff6851c39f0000, pid 1) on processor 0 due to Ke= yboard Entry [0]kdb> bp write_sysrq_trigger Instruction(i) BP #0 at 0xffffc02d2dd09290 (write_sysrq_trigger) is enabled addr at ffffc02d2dd09290, hardtype=3D0 installed=3D0 [0]kdb> go $ echo h > /proc/sysrq-trigger Entering kdb (current=3D0xffff6851c53c1840, pid 174) on processor 1 due to = Breakpoint @ 0xffffc02d2dd09290 [1]kdb> ss Entering kdb (current=3D0xffff6851c53c1840, pid 174) on processor 1 due to = SS trap @ 0xffffc02d2dd09294 [1]kdb> ss Entering kdb (current=3D0xffff6851c53c1840, pid 174) on processor 1 due to = SS trap @ 0xffffc02d2dd09298 [1]kdb> ss Entering kdb (current=3D0xffff6851c53c1840, pid 174) on processor 1 due to = SS trap @ 0xffffc02d2dd0929c [1]kdb> Fixes: 44679a4f142b ("arm64: KGDB: Add step debugging support") Co-developed-by: Wei Li Signed-off-by: Wei Li Signed-off-by: Sumit Garg Tested-by: Douglas Anderson --- arch/arm64/include/asm/debug-monitors.h | 1 + arch/arm64/kernel/debug-monitors.c | 5 +++++ arch/arm64/kernel/kgdb.c | 2 ++ 3 files changed, 8 insertions(+) diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/a= sm/debug-monitors.h index 7b7e05c02691..ce3875ad5cd3 100644 --- a/arch/arm64/include/asm/debug-monitors.h +++ b/arch/arm64/include/asm/debug-monitors.h @@ -104,6 +104,7 @@ void user_regs_reset_single_step(struct user_pt_regs *r= egs, void kernel_enable_single_step(struct pt_regs *regs); void kernel_disable_single_step(void); int kernel_active_single_step(void); +void kernel_regs_reset_single_step(struct pt_regs *regs); =20 #ifdef CONFIG_HAVE_HW_BREAKPOINT int reinstall_suspended_bps(struct pt_regs *regs); diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-m= onitors.c index 3da09778267e..9af898b22ed4 100644 --- a/arch/arm64/kernel/debug-monitors.c +++ b/arch/arm64/kernel/debug-monitors.c @@ -438,6 +438,11 @@ int kernel_active_single_step(void) } NOKPROBE_SYMBOL(kernel_active_single_step); =20 +void kernel_regs_reset_single_step(struct pt_regs *regs) +{ + set_regs_spsr_ss(regs); +} + /* ptrace API */ void user_enable_single_step(struct task_struct *task) { diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c index cda9c1e9864f..51f204bbcf87 100644 --- a/arch/arm64/kernel/kgdb.c +++ b/arch/arm64/kernel/kgdb.c @@ -224,6 +224,8 @@ int kgdb_arch_handle_exception(int exception_vector, in= t signo, */ if (!kernel_active_single_step()) kernel_enable_single_step(linux_regs); + else + kernel_regs_reset_single_step(linux_regs); err =3D 0; break; default: --=20 2.34.1