Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp2114562pxf; Sat, 3 Apr 2021 11:31:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJynu7JhGVll/MXhm1UZXy4ct0JXgYSqa8T28HLYdqBCReZdarOURn0TLwSVsot2WxRsiqXB X-Received: by 2002:a02:ca50:: with SMTP id i16mr17771279jal.5.1617474686536; Sat, 03 Apr 2021 11:31:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617474686; cv=none; d=google.com; s=arc-20160816; b=qAX+yNS+HJq0mi9S9DVk+cGxOmaBq3yKyyKFfu/prFGVo4OjwbKSAgXwMdFMvMqGqs ckfJQ8hqbgCkVZA717+3yhWqUuhXxK2vwyVB/Wuu37ZeRkajoIHlfs1OOZ3fYnz5abjV LOG14CpqegbCBYPJIgM5vVczyewTwYI1eNXb05/9MhzN4DpkQU8weC/P/GfmRfbbAmqH 6aIIMTKJ0b0B2A8l+LE2TSg4m0PkO23WYE//65TtNsdvimFm/7cxK7uZxBWalyqN0CBt do5IDx8CeJmSDER7S//06m5T9XCgtkYSeVpQdVSvVRLvqAAaujEyJoe7LVCtjR/RMmG+ iZnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=gq0erFc4uqrWwxR0D5R2dv7pkbhsk29OBJv19RzQL4E=; b=mJTs64APRBxm1qXiuRoQ1mtWoo2fwEgtZCs1VGPU6fpNl+Koocjkh6apUUxJdYzntA EX7OODpd2cpxMpiG1TyFYuIwPLxu/PoyqDkdFcS2Pz5SiEDyRgSRyNhLvVtZq2GsVTtm 6//b9SwGSU4DlzPF/0wG13Do5mvNEoOvWLvqd2bo1q8MKsSjV9Q/vo0bpLNCmxHSfjh0 XYIInCPunFDHKQTYCwpzRsff5n+U/pTrIuqSe/kjEXl6McQDFi3M1pkeqGuWcrjPvWMj 4+UD68YnRk9l/PE0D9F+Vz7AZISSc350gg/JZQ7pOEe6/3wyTAQpir9Yk1WwACvUOEIn 22Fg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x6si7982920ill.58.2021.04.03.11.31.11; Sat, 03 Apr 2021 11:31:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236403AbhDCSa6 (ORCPT + 99 others); Sat, 3 Apr 2021 14:30:58 -0400 Received: from angie.orcam.me.uk ([157.25.102.26]:38372 "EHLO angie.orcam.me.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230516AbhDCSa6 (ORCPT ); Sat, 3 Apr 2021 14:30:58 -0400 Received: by angie.orcam.me.uk (Postfix, from userid 500) id D1DEC92009C; Sat, 3 Apr 2021 20:30:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id C2E5592009B; Sat, 3 Apr 2021 20:30:53 +0200 (CEST) Date: Sat, 3 Apr 2021 20:30:53 +0200 (CEST) From: "Maciej W. Rozycki" To: Masami Hiramatsu cc: Jisheng Zhang , Paul Walmsley , Palmer Dabbelt , Albert Ou , Guo Ren , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] riscv: keep interrupts disabled for BREAKPOINT exception In-Reply-To: <20210401093036.037f2abbce7ed5d1e68466b7@kernel.org> Message-ID: References: <20210330021624.2b776386@xhacker> <20210330183316.942215efe8e6e8455ad14113@kernel.org> <20210331222244.45a5807c@xhacker> <20210401093036.037f2abbce7ed5d1e68466b7@kernel.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 1 Apr 2021, Masami Hiramatsu wrote: > > > > Current riscv's kprobe handlers are run with both preemption and > > > > interrupt enabled, this violates kprobe requirements. Fix this issue > > > > by keeping interrupts disabled for BREAKPOINT exception. > > > > > > Not only while the breakpoint exception but also until the end of > > > the single step (maybe you are using __BUG_INSN_32 ??) need to be > > > disable interrupts. Can this do that? > > > > > > > interrupt is disabled during "single step" by kprobes_save_local_irqflag() > > and kprobes_restore_local_irqflag(). The code flow looks like: > > > > do_trap_break() // for bp > > kprobe_breakpoint_handler() > > setup_singlestep() > > kprobes_restore_local_irqflag() > > > > do_trap_break() // for ss > > kprobe_single_step_handler() > > kprobes_restore_local_irqflag() > > OK, thanks for the confirmation! Is this approach guaranteed to keep interrupt handling latency low enough for the system not to be negatively affected, e.g. for the purpose of NTP timekeeping? Maciej