[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3] target/arm: Merge arm_cpu_vq_map_next_smaller into sole c
From: |
Peter Maydell |
Subject: |
Re: [PATCH v3] target/arm: Merge arm_cpu_vq_map_next_smaller into sole caller |
Date: |
Mon, 18 Nov 2019 13:15:58 +0000 |
On Mon, 18 Nov 2019 at 09:31, Andrew Jones <address@hidden> wrote:
>
> On Mon, Nov 18, 2019 at 10:14:14AM +0100, Richard Henderson wrote:
> > Coverity reports, in sve_zcr_get_valid_len,
> >
> > "Subtract operation overflows on operands
> > arm_cpu_vq_map_next_smaller(cpu, start_vq + 1U) and 1U"
> >
> > First, the aarch32 stub version of arm_cpu_vq_map_next_smaller,
> > returning 0, does exactly what Coverity reports. Remove it.
> >
> > Second, the aarch64 version of arm_cpu_vq_map_next_smaller has
> > a set of asserts, but they don't cover the case in question.
> > Further, there is a fair amount of extra arithmetic needed to
> > convert from the 0-based zcr register, to the 1-base vq form,
> > to the 0-based bitmap, and back again. This can be simplified
> > by leaving the value in the 0-based form.
> >
> > Finally, use test_bit to simplify the common case, where the
> > length in the zcr registers is in fact a supported length.
> >
> > Reported-by: Coverity (CID 1407217)
> > Signed-off-by: Richard Henderson <address@hidden>
> > ---
> >
> > v2: Merge arm_cpu_vq_map_next_smaller into sve_zcr_get_valid_len,
> > as suggested by Andrew Jones.
> >
> > v3: Use test_bit to make the code even more obvious; the
> > current_length + 1 thing to let us find current_length in the
> > bitmap seemed unnecessarily clever. (For real this time).
> Reviewed-by: Andrew Jones <address@hidden>
Applied to target-arm.next, thanks.
-- PMM