> emit_call_libgcc_ll() zero-extends the ALU32 operands and calls the
> unsigned hppa_div64()/hppa_div64_rem() helpers regardless of the BPF
> instruction's signedness, so the parisc64 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.
>
> Add hppa_sdiv64()/hppa_sdiv64_rem() wrapping div64_s64(), thread
> is_signed = (insn->off == 1) through the div/mod emit sites, and on the
> signed path sign-extend the ALU32 operands (and the immediate divisor)
> instead of zero-extending them before calling the signed helpers.
> bpf_do_misc_fixups() rewrites the zero-divisor and INT_MIN/-1 cases out
> of the instruction stream before the JIT runs.
>
> Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com>

This looks like a fix for a correctness bug that has been present since
the parisc64 eBPF JIT was first added, where signed div/mod produced an
unsigned result for negative operands.

Should this carry a Fixes: tag?

  Fixes: c95e269773b3 ("parisc: Add 64-bit eBPF JIT compiler")


---
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/29607384764