Received: by 2002:a05:6358:7058:b0:131:369:b2a3 with SMTP id 24csp5015105rwp; Sun, 16 Jul 2023 17:07:08 -0700 (PDT) X-Google-Smtp-Source: APBJJlH/qN5aT1XpfKE36MJEU/+fAVdd50X5dBTIr9CXLekcSkXSLBupMvYpeioeInFzKmHaPVNa X-Received: by 2002:a17:90b:24e:b0:262:eb20:2dd8 with SMTP id fz14-20020a17090b024e00b00262eb202dd8mr11229686pjb.20.1689552428210; Sun, 16 Jul 2023 17:07:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689552428; cv=none; d=google.com; s=arc-20160816; b=GSC3zXpA6l1jowH4Cgipd5p4ajJkqdQs2MuFrtcXwhyZ550/0swdPTAnmTcmGGAB/o hsAPCkgX8ltba9AIXq1hjWGCmgK0CbCUPgu+6X9GMP/jKyD6XtMEES02MR1nk0CbAwxE 1J3ebDIqa4NYuaRsZOrk/eqxGiKkA5ze051p/B9ZvSUXicIsEsDQRuozzgwrySG0sc1x av1Gc3P7jvDg1OXmmhYKDs2c2fgRPRVkACyhPKtJzxAo/tr/7c5k0jtEAggz5Y/Y5Kvk FXjxxb6SsH7zvwpxFfrpTcAJ6gmGB1K9lt3B7q/aKgXeDphyPoLjUsBUHxEmEtKrPc/O wKqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=fu0ffKJyJxJJ1P7qXiBob3njBJOIGaY9XYKN/letugw=; fh=Jlkiqm9apBuhlHu9r/RdujF1X6wDlk/YnNalp151ayU=; b=JIEJNqD6VDuv2d/Uvh53U+ZybVVYHhYAY2TAv/QCRGtcJs6r7Lw09NUheVeArYY2vK db3cbdGWa8L+BiVFQo8OeHWLpelsswhdmcI9w/b4yUY93zKqo/U01ZtuT8kaaEOBVJYt CPaMVc1/GVTqnj79e0pyF93wI2il6v837H5tMmquyt8v5R72Xu49DHrd7GKTZgJGoMLa ZY6NPB94L2Qod7XlWm/SZZnSnjZUg5+pMzuuEvQUAhvWKClqWanm1V09CcyWVV9Q3pJP Gixej7fLJRGWZjhiNz7lc+D9zJnAKk8/yYAXOzwMMHP5/eOJHC8/dPw3cxYedwkHbn+f 7LcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=KPedHonJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ot4-20020a17090b3b4400b0026384c02c03si5102581pjb.140.2023.07.16.17.06.53; Sun, 16 Jul 2023 17:07:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=KPedHonJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230071AbjGPXdl (ORCPT + 99 others); Sun, 16 Jul 2023 19:33:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229461AbjGPXdl (ORCPT ); Sun, 16 Jul 2023 19:33:41 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C6A3D1; Sun, 16 Jul 2023 16:33:40 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9840160EE9; Sun, 16 Jul 2023 23:33:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2567C43395; Sun, 16 Jul 2023 23:33:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689550419; bh=Ja9IYjqwNzmeISofK1hhZQkSnGHcbD0jYQgPpeuxanI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=KPedHonJ+1xUSpZC+ZJSrhK2jIwbYYKVbiPMKpYSv4IL0MiL6siOsXnqw+/xzA7+q lfvdor5Cbw2vewFsyp34mOQLyiQtZTC2tusnrYIhlc1EGfBd/+VxBh3fD67SMuNLso pV8S+REUQIE5/NFGCVLMhr7hi0oSOGkNvw+eRDAwHYuu+cQ5hTV1aaTsjWeN8tE5na PC2lUeWK6tLqdR5XvGETNXi56UsoXGWCsUoiTsh3GLekmJ/1nkcJIJt5yhpPZKGHjn wWeaZJuNM5gJWC9ksjdpXZcc64tIX21zGaxmoEqcxpnF9N2zgZMwMl44QfnJ0l9tY9 RtrRsd8lABtWg== Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-51cff235226so8115760a12.0; Sun, 16 Jul 2023 16:33:38 -0700 (PDT) X-Gm-Message-State: ABy/qLZQxX+wY34Wd2i2cDJEr7tqrDOxYVIygcV0osdI2EW85AbD1vNk v8F3BDK0xL30BJtT1WkO1pjEqgOm4wDo0OeRbcw= X-Received: by 2002:a05:6402:524e:b0:51d:cf7b:c9f0 with SMTP id t14-20020a056402524e00b0051dcf7bc9f0mr11056350edd.12.1689550417039; Sun, 16 Jul 2023 16:33:37 -0700 (PDT) MIME-Version: 1.0 References: <20230702025708.784106-1-guoren@kernel.org> <20230704164003.GB83892@hirez.programming.kicks-ass.net> <20230710080152.GA3028865@hirez.programming.kicks-ass.net> In-Reply-To: <20230710080152.GA3028865@hirez.programming.kicks-ass.net> From: Guo Ren Date: Mon, 17 Jul 2023 07:33:25 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] riscv: entry: Fixup do_trap_break from kernel side To: Peter Zijlstra Cc: arnd@arndb.de, palmer@rivosinc.com, tglx@linutronix.de, luto@kernel.org, conor.dooley@microchip.com, heiko@sntech.de, jszhang@kernel.org, lazyparser@gmail.com, falcon@tinylab.org, chenhuacai@kernel.org, apatel@ventanamicro.com, atishp@atishpatra.org, mark.rutland@arm.com, bjorn@kernel.org, palmer@dabbelt.com, bjorn@rivosinc.com, daniel.thompson@linaro.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, stable@vger.kernel.org, Guo Ren Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 10, 2023 at 4:02=E2=80=AFPM Peter Zijlstra wrote: > > On Sun, Jul 09, 2023 at 10:30:22AM +0800, Guo Ren wrote: > > On Wed, Jul 5, 2023 at 12:40=E2=80=AFAM Peter Zijlstra wrote: > > > > > > On Sat, Jul 01, 2023 at 10:57:07PM -0400, guoren@kernel.org wrote: > > > > From: Guo Ren > > > > > > > > The irqentry_nmi_enter/exit would force the current context into in= _interrupt. > > > > That would trigger the kernel to dead panic, but the kdb still need= s "ebreak" to > > > > debug the kernel. > > > > > > > > Move irqentry_nmi_enter/exit to exception_enter/exit could correct = handle_break > > > > of the kernel side. > > > > > > This doesn't explain much if anything :/ > > > > > > I'm confused (probably because I don't know RISC-V very well), what's > > > EBREAK and how does it happen? > > EBREAK is just an instruction of riscv which would rise breakpoint exce= ption. > > > > > > > > > > Specifically, if EBREAK can happen inside an local_irq_disable() regi= on, > > > then the below change is actively wrong. Any exception/interrupt that > > > can happen while local_irq_disable() must be treated like an NMI. > > When the ebreak happend out of local_irq_disable region, but > > __nmi_enter forces handle_break() into in_interupt() state. So how > > And why is that a problem? I think I'm missing something fundamental > here... The irqentry_nmi_enter() would force the current context to get in_interrupt=3Dtrue, although ebreak happens in the context which is in_interrupt=3Dfalse. A lot of checking codes, such as: if (in_interrupt()) panic("Fatal exception in interrupt"); It would make the kernel panic, but we don't panic; we want back to the she= ll. eg: echo BUG > /sys/kernel/debug/provoke-crash/DIRECT > > > about: > > > > diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c > > index f910dfccbf5d..69f7043a98b9 100644 > > --- a/arch/riscv/kernel/traps.c > > +++ b/arch/riscv/kernel/traps.c > > @@ -18,6 +18,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include > > @@ -285,12 +286,18 @@ asmlinkage __visible __trap_section void > > do_trap_break(struct pt_regs *regs) > > handle_break(regs); > > > > irqentry_exit_to_user_mode(regs); > > - } else { > > + } else if (in_interrupt()){ > > irqentry_state_t state =3D irqentry_nmi_enter(regs); > > > > handle_break(regs); > > > > irqentry_nmi_exit(regs, state); > > + } else { > > + enum ctx_state prev_state =3D exception_enter(); > > + > > + handle_break(regs); > > + > > + exception_exit(prev_state); > > } > > } > > That's wrong. If you want to make it conditional, you have to look at > !(regs->status & SR_IE) (that's the interrupt enable flag of the > interrupted context, right?) > > When you hit an EBREAK when IRQs were disabled, you must be NMI like. > > But making it conditional like this makes it really hard to write a > handler though, it basically must assume it will be NMI contetx (because > it can't know) so there is no point in sometimes not doing NMI context. --=20 Best Regards Guo Ren