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,