On Thu, 27 Jan 2022 16:21:24 +0000, James Morse wrote:
> aarch64_insn_gen_logical_immediate() is generating the wrong code if
> it is handed a 64bit immediate which has a single span of 1s (i.e. a
> mask), with bit 63 set, and 0s in the remaining upper 32 bits.
> Clear as mud. An example always helps: 0x800000003fffffff would be wrongly
> encoded, but 0x000000003fffffff is unaffected.
>
> It would appear eBPF is unable to hit these cases, as build_insn()'s
> imm value is a s32, so when used with BPF_ALU64, the sign-extended
> u64 immediate would always have all-1s or all-0s in the upper 32 bits.
>
> [...]
Applied to arm64 (for-next/insn), thanks!
[1/3] arm64: selftests: Generate all the possible logical immediates as a header
(no commit info)
[2/3] arm64: insn: Add tests for aarch64_insn_gen_logical_immediate()
(no commit info)
[3/3] arm64: insn: Generate 64 bit mask immediates correctly
https://git.kernel.org/arm64/c/a6aab0188299
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
