Re: [PATCH bpf-next v4 18/20] selftests/bpf: Add an end-to-end .bpf_cleanup exception test

[Yonghong Song <yonghong.song@linux.dev>]

On 9/21/26 2:22 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Medium] bpf: endianness bug in raw BPF instruction emission
> - [Low] bpf: BPF Comment Style Violation
> --
>
> commit 322ad0f798ee8015c8f51c953009198fc70b2b9b
> Author: Yonghong Song <yonghong.song@linux.dev>
>
> selftests/bpf: Add an end-to-end .bpf_cleanup exception test
>
> This commit adds an end-to-end test for exception cleanup using .bpf_cleanup
> records. It defines inline assembly constructs mimicking compiler output to
> evaluate how the kernel handles and optionally rejects various landing pad
> combinations and malformed paths.
>
>> diff --git a/tools/testing/selftests/bpf/prog_tests/exceptions_cleanup.c b/tools/testing/selftests/bpf/prog_tests/exceptions_cleanup.c
>> new file mode 100644
>> index 0000000000000..c932da7cbec16
>> --- /dev/null
>> +++ b/tools/testing/selftests/bpf/prog_tests/exceptions_cleanup.c
>> @@ -0,0 +1,121 @@
> [ ... ]
>> +/* A table with more records than the program has instructions: no valid one
>> + * can look like that, and it is refused before the kernel allocates for it.
>> + */
> [Severity: Low]
> Does this code adhere to the BPF comment style guidelines?
>
> The BPF subsystem requires multi-line comments to have the opening '/*'
> on its own line, with the comment text starting on the next line. In
> test_cleanup_info_cnt(), the text starts on the same line as the opening.
>
>
[...]

> [ ... ]
>> +	/* gotox r2, as a raw insn: the mnemonic only reached the LLVM
>> +	 * assembler in llvm 22, and BPF_RAW_INSN() needs <linux/bpf.h>, which
>> +	 * vmlinux.h rules out.
>> +	 */
>> +	".8byte 0x20d;"
> [Severity: Medium]
> Will this raw instruction emission work correctly on big-endian architectures?
>
> The inline assembly in gotox_in_pad() emits a 64-bit integer literal. On a
> little-endian target, 0x20d places the correct opcode bytes at the start
> (offset 0). However, on a big-endian target, the 64-bit value is emitted with
> leading zeros, placing 0x00 in the code byte. This corrupts the instruction
> stream and will cause the BPF verifier to reject it.
>
>> +"l0_%=:"
>> +	"call bpf_unwind_resume;"
>> +	"exit;"
> [ ... ]
>> +	/* r0 = *(u32 *)skb[0]. Spelled as a raw insn because BPF_LD_ABS()
>> +	 * needs <linux/filter.h>, which this file cannot have -- vmlinux.h
>> +	 * already defines the uapi enums.
>> +	 */
>> +	".8byte 0x20;"
> [Severity: Medium]
> Similarly here in ld_abs_in_pad(), does emitting 0x20 as an 8-byte literal
> corrupt the instruction stream on big-endian architectures?
>
> On big-endian targets, this will evaluate with 0x00 at the code byte instead
> of BPF_LD_ABS (0x20), causing malformed instructions to be passed to the
> verifier.

Will fix endian issue.

>
>> +	"call bpf_unwind_resume;"
>> +	"exit;"
>> +	CLEANUP_REC("1b", "2b", "3b")