From: Mark Rutland <mark.rutland@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Marc Zyngier <maz@kernel.org>,
Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Mark Brown <broonie@kernel.org>,
kvmarm@lists.linux.dev
Subject: Re: [PATCH V3 7/7] arm64/hw_breakpoint: Enable FEAT_Debugv8p9
Date: Mon, 16 Dec 2024 10:58:29 +0000 [thread overview]
Message-ID: <Z2AH1SN5CipWkkE4@J2N7QTR9R3> (raw)
In-Reply-To: <20241216040831.2448257-8-anshuman.khandual@arm.com>
On Mon, Dec 16, 2024 at 09:38:31AM +0530, Anshuman Khandual wrote:
> Currently there can be maximum 16 breakpoints, and 16 watchpoints available
> on a given platform - as detected from ID_AA64DFR0_EL1.[BRPs|WRPs] register
> fields. But these breakpoint, and watchpoints can be extended further up to
> 64 via a new arch feature FEAT_Debugv8p9.
>
> This first enables banked access for the breakpoint and watchpoint register
> set via MDSELR_EL1, extended exceptions via MDSCR_EL1.EMBWE and determining
> available breakpoints and watchpoints in the platform from ID_AA64DFR1_EL1,
> when FEAT_Debugv8p9 is enabled.
[...]
> +static u64 read_wb_reg(int reg, int n)
> +{
> + unsigned long flags;
> + u64 val;
> +
> + if (!is_debug_v8p9_enabled())
> + return __read_wb_reg(reg, n);
> +
> + /*
> + * Bank selection in MDSELR_EL1, followed by an indexed read from
> + * breakpoint (or watchpoint) registers cannot be interrupted, as
> + * that might cause misread from the wrong targets instead. Hence
> + * this requires mutual exclusion.
> + */
> + local_irq_save(flags);
> + write_sysreg_s(SYS_FIELD_PREP(MDSELR_EL1, BANK, n / MAX_PER_BANK), SYS_MDSELR_EL1);
> + isb();
> + val = __read_wb_reg(reg, n % MAX_PER_BANK);
> + local_irq_restore(flags);
> + return val;
> +}
> NOKPROBE_SYMBOL(read_wb_reg);
I don't believe that disabling interrupts here is sufficient. On the
last version I asked about the case of racing with a watchpoint handler:
| For example, what prevents watchpoint_handler() from firing in the
| middle of arch_install_hw_breakpoint() or
| arch_uninstall_hw_breakpoint()?
... and disabling interrupts cannot prevent that, because
local_irq_{save,restore}() do not affect the behaviour of watchpoints or
breakpoints.
Please can you try to answer the questions I asked last time, i.e.
| What prevents a race with an exception handler? e.g.
|
| * Does the structure of the code prevent that somehow?
|
| * What context(s) does this code execute in?
| - Are debug exceptions always masked?
| - Do we disable breakpoints/watchpoints around (some) manipulation of
| the relevant registers?
... and the question form the earlier comment, i.e.
| Is the existing code correct?
I suspect that the existing code might not have the necessary mutual
exclusion in all cases, but it's difficult to trigger an issue by
accident. Is there any way a handler could race with some other
manipulation of watchpoints/breakpoints such that some data structure
gets corrupted, or such that the kernel deadlocks?
Mark.
next prev parent reply other threads:[~2024-12-16 11:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-16 4:08 [PATCH V3 0/7] arm64/hw_breakpoint: Enable FEAT_Debugv8p9 Anshuman Khandual
2024-12-16 4:08 ` [PATCH V3 1/7] arm64/sysreg: Update register fields for ID_AA64MMFR0_EL1 Anshuman Khandual
2024-12-16 4:08 ` [PATCH V3 2/7] arm64/sysreg: Add register fields for MDSELR_EL1 Anshuman Khandual
2024-12-16 4:08 ` [PATCH V3 3/7] arm64/sysreg: Add register fields for HDFGRTR2_EL2 Anshuman Khandual
2024-12-16 4:08 ` [PATCH V3 4/7] arm64/sysreg: Add register fields for HDFGWTR2_EL2 Anshuman Khandual
2024-12-16 4:08 ` [PATCH V3 5/7] arm64/cpufeature: Add field details for ID_AA64DFR1_EL1 register Anshuman Khandual
2024-12-16 4:08 ` [PATCH V3 6/7] arm64/boot: Enable EL2 requirements for FEAT_Debugv8p9 Anshuman Khandual
2024-12-16 23:42 ` Rob Herring
2024-12-17 8:48 ` Anshuman Khandual
2024-12-17 17:53 ` Rob Herring
2024-12-18 5:25 ` Anshuman Khandual
2024-12-18 9:10 ` Marc Zyngier
2024-12-18 13:15 ` Mark Brown
2024-12-16 4:08 ` [PATCH V3 7/7] arm64/hw_breakpoint: Enable FEAT_Debugv8p9 Anshuman Khandual
2024-12-16 10:58 ` Mark Rutland [this message]
2026-03-31 22:58 ` Rob Herring
2026-04-02 10:37 ` Mark Rutland
2026-04-02 17:46 ` Rob Herring
2026-04-09 10:52 ` Mark Rutland
2026-04-10 19:55 ` Rob Herring
2026-04-13 8:48 ` Mark Rutland
2026-03-31 23:02 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z2AH1SN5CipWkkE4@J2N7QTR9R3 \
--to=mark.rutland@arm.com \
--cc=anshuman.khandual@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=james.morse@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox