Re: [PATCH bpf-next v2 2/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc32 JIT

[bot+bpf-ci]

> commit 78e60eb41cf96a6559947f9582f1a6e1e10551af
> Author: Nicholas Dudar <main.kalliope@xxxxxxxxx>
>
>     bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc32 JIT
>
>     emit_alu_r32() and emit_alu_r64() call the unsigned millicode
>     ($$divU/$$remU) and libgcc-style (hppa_div64()/hppa_div64_rem())
>     divide/remainder helpers for BPF_DIV and BPF_MOD regardless of the
>     BPF instruction's signedness, so the parisc32 JIT does not implement
>     signed BPF_SDIV and BPF_SMOD (off == 1). Signed ALU32 and ALU64
>     div/mod get an unsigned quotient and remainder rather than the
>     verifier's and the interpreter's signed result for negative operands.
>
>     Thread is_signed = (insn->off == 1) through emit_alu_r32()/
>     emit_alu_r64(), and on the signed path use the $$divI/$$remI signed
>     millicode routines (32-bit) or the hppa_sdiv64()/hppa_sdiv64_rem()
>     helpers added in patch 1 (64-bit) instead of their unsigned
>     counterparts. $$divI and $$remI are extern-declared and exported next
>     to $$divU/$$remU in arch/parisc/kernel/parisc_ksyms.c.
>     bpf_do_misc_fixups() rewrites the zero-divisor and INT_MIN/-1 cases out
>     of the instruction stream before the JIT runs.
>
>     Acked-by: Helge Deller <deller@xxxxxx>
>     Tested-by: Helge Deller <deller@xxxxxx>
>     Assisted-by: Claude:claude-opus-4-8
>     Signed-off-by: Nicholas Dudar <main.kalliope@xxxxxxxxx>

This looks like a bug fix for the parisc32 JIT's handling of signed
division and modulo operations. Should this include a Fixes: tag?

  Fixes: 847b98421362 ("adding ci files")

This isn't a bug, but would it be worth naming the sibling commit (or
saying "the previous patch") instead of "patch 1" here, so the reference
still makes sense once the series is applied?

>     helpers added in patch 1 (64-bit) instead of their unsigned

The "patch 1" reference is only resolvable while the series is on the
list. Once the commits land, git history has no "patch 1" for later
readers or anyone doing archaeology on this code.


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/34922459599