[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <75faf0ec-79ee-4631-91d0-535c81c1bc85@sirena.org.uk>
Date: Wed, 23 Jul 2025 12:13:20 +0100
From: Mark Brown <broonie@...nel.org>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Jeremy Linton <jeremy.linton@....com>,
linux-trace-kernel@...r.kernel.org,
linux-perf-users@...r.kernel.org, mhiramat@...nel.org,
oleg@...hat.com, peterz@...radead.org, acme@...nel.org,
namhyung@...nel.org, mark.rutland@....com,
alexander.shishkin@...ux.intel.com, jolsa@...nel.org,
irogers@...gle.com, adrian.hunter@...el.com,
kan.liang@...ux.intel.com, thiago.bauermann@...aro.org,
yury.khrustalev@....com, kristina.martsenko@....com,
liaochang1@...wei.com, will@...nel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 5/8] arm64: probes: Add GCS support to bl/blr/ret
On Wed, Jul 23, 2025 at 11:00:33AM +0100, Catalin Marinas wrote:
> On Fri, Jul 18, 2025 at 11:37:37PM -0500, Jeremy Linton wrote:
> > @@ -133,17 +147,26 @@ simulate_br_blr(u32 opcode, long addr, struct pt_regs *regs)
> > /* update pc first in case we're doing a "blr lr" */
> > instruction_pointer_set(regs, get_x_reg(regs, xn));
> >
> > - /* Link register is x30 */
> > if (((opcode >> 21) & 0x3) == 1)
> > - set_x_reg(regs, 30, addr + 4);
> > + update_lr(regs, addr);
> > }
> I can see why this function was originally updating PC (in case of a blr
> lr) but updating the LR was not supposed to fail. With GCS, I think we
> should follow similar logic to simulate_b_bl() and skip updating PC/LR
> if the write to the GCS failed (assuming that's what the hardware does,
> I haven't checked the spec).
Yes, the pseudocode does the GCS validation before it starts updating
BTYPE or any of the registers.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists