[PATCH v2] target/arm: Fix signed integer overflow undefined behavior.

this fixed, since the error is showing up when I enable clang's sanitizers while looking for other issues. Changes from v1: From peter.mayd...@linaro.org's review, only changing the internal representation from int to uint32_t, and leaving the API types the same. Signed-off-by: Stephen Long

Re: [PATCH] target/arm: Fix signed integer overflow undefined behavior.

On Wed, Feb 19, 2025 at 7:26 AM Peter Maydell wrote: > On Tue, 18 Feb 2025 at 22:22, Stephen Longfield > wrote: > > > > The problem is internal to t32_expandimm_imm, the imm intermediate > > immediate value. This value is sourced from x, which always comes from >

[PATCH] target/arm: Fix signed integer overflow undefined behavior.

4/www/docs/n1548.pdf this is undefined behavior. Though this is a minor undefined behavior, I'd like to see this fixed, since the error is showing up when I enable clang's sanitizers while looking for other issues. Signed-off-by: Stephen Longfield Signed-off-by: Roque Arcudia Hernandez

Re: Possible race condition in aspeed ast2600 smp boot on TCG QEMU

? > > Adding Aspeed Engineers. This reminds me of a discussion a while ago. > > > > On 1/11/24 18:38, Stephen Longfield wrote: > > > We’ve noticed inconsistent behavior when running a large number of aspeed > > ast2600 executions, that seems to be tied to a race conditio

Re: Possible race condition in aspeed ast2600 smp boot on TCG QEMU

d the 2nd core gets released from its mailbox polling loop. On Thu, Jan 11, 2024 at 9:38 AM Stephen Longfield wrote: > We’ve noticed inconsistent behavior when running a large number of aspeed > ast2600 executions, that seems to be tied to a race condition in the smp > boot when executi

Possible race condition in aspeed ast2600 smp boot on TCG QEMU

We’ve noticed inconsistent behavior when running a large number of aspeed ast2600 executions, that seems to be tied to a race condition in the smp boot when executing on TCG-QEMU, and were wondering what a good mediation strategy might be. The problem first shows up as part of SMP boot. On a run t

Re: [PATCH] hw/net: Fix read of uninitialized memory in ftgmac100

Does anything more need to happen with this patch before it can be applied? Not sure if it had gotten lost over the holidays. Best, --Stephen On Wed, Dec 21, 2022 at 9:58 AM Stephen Longfield wrote: > > On Tue, Dec 20, 2022 at 11:30 PM Cédric Le Goater wrote: > > > >

[PATCH] hw/net: Fix read of uninitialized memory in imx_fec.

by c...@kaod.org during the code review of a similar patch to hw/net/ftgmac100.c Change-Id: Ib0464303b191af1e28abeb2f5105eb25aadb5e9b Signed-off-by: Stephen Longfield Reviewed-by: Patrick Venture --- hw/net/imx_fec.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/h

Re: [PATCH] hw/net: Fix read of uninitialized memory in ftgmac100

On Tue, Dec 20, 2022 at 11:30 PM Cédric Le Goater wrote: > > On 12/20/22 23:14, Stephen Longfield wrote: > > With the `size += 4` before the call to `crc32`, the CRC calculation > > would overrun the buffer. Size is used in the while loop starting on > > line 1009 to de

[PATCH] hw/net: Fix read of uninitialized memory in ftgmac100

computation. I'm unsure why this use of uninitialized memory in the CRC doesn't result in CRC errors, but it seems clear to me that it should not be included in the calculation. Signed-off-by: Stephen Longfield Reviewed-by: Hao Wu --- hw/net/ftgmac100.c | 4 ++-- 1 file changed, 2 insert