On Mon, Feb 07, 2022 at 03:20:32PM +0000, Mark Brown wrote:
Since all the fields in the main ID registers are 4 bits wide we have up until now not bothered specifying the width in the code. Since we now wish to use this mechanism to enumerate features from the floating point feature registers which do not follow this pattern add a width to the table. This means updating all the existing table entries but makes it less likely that we run into issues in future due to implicitly assuming a 4 bit width.
Signed-off-by: Mark Brown broonie@kernel.org
Do we leave this one alone on purpose?
.desc = "GIC system register CPU interface", .capability = ARM64_HAS_SYSREG_GIC_CPUIF, .type = ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE, .matches = has_useable_gicv3_cpuif, .sys_reg = SYS_ID_AA64PFR0_EL1, .field_pos = ID_AA64PFR0_GIC_SHIFT, .sign = FTR_UNSIGNED, .min_field_value = 1,
Since width == 0, it will generate an undefined behavior.
UBSAN: shift-out-of-bounds in ./arch/arm64/include/asm/cpufeature.h:535:49 shift exponent 64 is too large for 64-bit type 'long long unsigned int' CPU: 0 PID: 0 Comm: swapper Not tainted 5.17.0-rc6-next-20220301 #1 Call trace: dump_backtrace show_stack dump_stack_lvl dump_stack ubsan_epilogue __ubsan_handle_shift_out_of_bounds has_cpuid_feature cpuid_feature_extract_unsigned_field_width at arch/arm64/include/asm/cpufeature.h:535 (inlined by) cpuid_feature_extract_field_width at arch/arm64/include/asm/cpufeature.h:582 (inlined by) cpuid_feature_extract_field_width at arch/arm64/include/asm/cpufeature.h:578 (inlined by) feature_matches at arch/arm64/kernel/cpufeature.c:1317 (inlined by) has_cpuid_feature at arch/arm64/kernel/cpufeature.c:1335 has_useable_gicv3_cpuif has_useable_gicv3_cpuif at arch/arm64/kernel/cpufeature.c:1389 update_cpu_capabilities init_cpu_features cpuinfo_store_boot_cpu smp_prepare_boot_cpu start_kernel __primary_switched