On Mon, 18 Nov 2019 at 09:31, Andrew Jones <[email protected]> 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 <[email protected]> > > --- > > > > 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 <[email protected]> Applied to target-arm.next, thanks. -- PMM
