AI Trajectory


Trajectory: (Expand/Collapse All)
Seq Timestamp Type Name Duration
0/0 2026/07/17 23:08 flow patch-triage
0m Args: 
null

Results: 
{
  "EnableConfigs": [
    "BPF_JIT"
  ],
  "FocusSymbols": [
    "hppa_sdiv64",
    "hppa_sdiv64_rem",
    "emit_alu_r64",
    "emit_alu_r32",
    "emit_call_libgcc_ll"
  ],
  "Reasoning": "The patch adds support for signed division and modulo operations to the PA-RISC BPF JIT compiler. This is functional architecture-specific code that can be reached when running BPF programs on PA-RISC (which can be emulated in QEMU).",
  "WorthFuzzing": true
}
1/1 2026/07/17 23:08 action read-patch-diff
0m Args: 
null

Results: 
{
  "PatchDiff": "commit 4399dfba6c7361e0c4ce05f5e79abdddda0243cf\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Fri Jul 17 23:08:23 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/arch/parisc/net/bpf_jit.h b/arch/parisc/net/bpf_jit.h\nindex 8b8896959f0449..074115c93c909c 100644\n--- a/arch/parisc/net/bpf_jit.h\n+++ b/arch/parisc/net/bpf_jit.h\n@@ -467,6 +467,8 @@ static inline u32 hppa_t21_insn(u8 opcode, u8 r2, u8 r1, u8 ext8, u8 t)\n \n u64 hppa_div64(u64 div, u64 divisor);\n u64 hppa_div64_rem(u64 div, u64 divisor);\n+u64 hppa_sdiv64(u64 div, u64 divisor);\n+u64 hppa_sdiv64_rem(u64 div, u64 divisor);\n \n /* Helper functions that emit HPPA instructions when possible. */\n \ndiff --git a/arch/parisc/net/bpf_jit_comp32.c b/arch/parisc/net/bpf_jit_comp32.c\nindex 5ff0cf925fe953..eea0a34a3bfee7 100644\n--- a/arch/parisc/net/bpf_jit_comp32.c\n+++ b/arch/parisc/net/bpf_jit_comp32.c\n@@ -321,6 +321,8 @@ static void bpf_put_reg32(const s8 *reg, const s8 *src,\n extern void $$mulI(void);\n extern void $$divU(void);\n extern void $$remU(void);\n+extern void $$divI(void);\n+extern void $$remI(void);\n \n static void emit_call_millicode(void *func, const s8 arg0,\n \t\tconst s8 arg1, u8 opcode, struct hppa_jit_context *ctx)\n@@ -562,12 +564,14 @@ static void emit_alu_i32(const s8 *dst, s32 imm,\n }\n \n static void emit_alu_r64(const s8 *dst, const s8 *src,\n-\t\t\t struct hppa_jit_context *ctx, const u8 op)\n+\t\t\t struct hppa_jit_context *ctx, const u8 op,\n+\t\t\t bool is_signed)\n {\n \tconst s8 *tmp1 = regmap[TMP_REG_1];\n \tconst s8 *tmp2 = regmap[TMP_REG_2];\n \tconst s8 *rd;\n \tconst s8 *rs = bpf_get_reg64(src, tmp2, ctx);\n+\tvoid *func;\n \n \tif (op == BPF_MOV)\n \t\trd = bpf_get_reg64_ref(dst, tmp1, false, ctx);\n@@ -604,10 +608,12 @@ static void emit_alu_r64(const s8 *dst, const s8 *src,\n \t\temit_call_libgcc_ll(__muldi3, rd, rs, op, ctx);\n \t\tbreak;\n \tcase BPF_DIV:\n-\t\temit_call_libgcc_ll(\u0026hppa_div64, rd, rs, op, ctx);\n+\t\tfunc = is_signed ? \u0026hppa_sdiv64 : \u0026hppa_div64;\n+\t\temit_call_libgcc_ll(func, rd, rs, op, ctx);\n \t\tbreak;\n \tcase BPF_MOD:\n-\t\temit_call_libgcc_ll(\u0026hppa_div64_rem, rd, rs, op, ctx);\n+\t\tfunc = is_signed ? \u0026hppa_sdiv64_rem : \u0026hppa_div64_rem;\n+\t\temit_call_libgcc_ll(func, rd, rs, op, ctx);\n \t\tbreak;\n \tcase BPF_LSH:\n \t\temit_call_libgcc_ll(__ashldi3, rd, rs, op, ctx);\n@@ -630,7 +636,8 @@ static void emit_alu_r64(const s8 *dst, const s8 *src,\n }\n \n static void emit_alu_r32(const s8 *dst, const s8 *src,\n-\t\t\t struct hppa_jit_context *ctx, const u8 op)\n+\t\t\t struct hppa_jit_context *ctx, const u8 op,\n+\t\t\t bool is_signed)\n {\n \tconst s8 *tmp1 = regmap[TMP_REG_1];\n \tconst s8 *tmp2 = regmap[TMP_REG_2];\n@@ -666,10 +673,12 @@ static void emit_alu_r32(const s8 *dst, const s8 *src,\n \t\temit_call_millicode($$mulI, lo(rd), lo(rs), op, ctx);\n \t\tbreak;\n \tcase BPF_DIV:\n-\t\temit_call_millicode($$divU, lo(rd), lo(rs), op, ctx);\n+\t\temit_call_millicode(is_signed ? $$divI : $$divU,\n+\t\t\t\t    lo(rd), lo(rs), op, ctx);\n \t\tbreak;\n \tcase BPF_MOD:\n-\t\temit_call_millicode($$remU, lo(rd), lo(rs), op, ctx);\n+\t\temit_call_millicode(is_signed ? $$remI : $$remU,\n+\t\t\t\t    lo(rd), lo(rs), op, ctx);\n \t\tbreak;\n \tcase BPF_LSH:\n \t\temit(hppa_subi(0x1f, lo(rs), HPPA_REG_T0), ctx);\n@@ -1163,12 +1172,12 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,\n \t\t\temit_imm32(tmp2, imm, ctx);\n \t\t\tsrc = tmp2;\n \t\t}\n-\t\temit_alu_r64(dst, src, ctx, BPF_OP(code));\n+\t\temit_alu_r64(dst, src, ctx, BPF_OP(code), off == 1);\n \t\tbreak;\n \n \t/* dst = -dst */\n \tcase BPF_ALU64 | BPF_NEG:\n-\t\temit_alu_r64(dst, tmp2, ctx, BPF_OP(code));\n+\t\temit_alu_r64(dst, tmp2, ctx, BPF_OP(code), false);\n \t\tbreak;\n \n \tcase BPF_ALU64 | BPF_MOV | BPF_K:\n@@ -1211,7 +1220,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,\n \t\t\temit_imm32(tmp2, imm, ctx);\n \t\t\tsrc = tmp2;\n \t\t}\n-\t\temit_alu_r32(dst, src, ctx, BPF_OP(code));\n+\t\temit_alu_r32(dst, src, ctx, BPF_OP(code), off == 1);\n \t\tbreak;\n \n \t/* dst = dst OP imm */\n@@ -1236,7 +1245,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,\n \t\t * src is ignored---choose tmp2 as a dummy register since it\n \t\t * is not on the stack.\n \t\t */\n-\t\temit_alu_r32(dst, tmp2, ctx, BPF_OP(code));\n+\t\temit_alu_r32(dst, tmp2, ctx, BPF_OP(code), false);\n \t\tbreak;\n \n \t/* dst = BSWAP##imm(dst) */\ndiff --git a/arch/parisc/net/bpf_jit_comp64.c b/arch/parisc/net/bpf_jit_comp64.c\nindex 54b0d5e25e0246..c326fa737ec8c5 100644\n--- a/arch/parisc/net/bpf_jit_comp64.c\n+++ b/arch/parisc/net/bpf_jit_comp64.c\n@@ -502,14 +502,19 @@ static void emit_call(u64 addr, bool fixed, struct hppa_jit_context *ctx)\n \temit_hppa_copy(HPPA_REG_RET0, regmap[BPF_REG_0], ctx);\n }\n \n-static void emit_call_libgcc_ll(void *func, const s8 arg0,\n-\t\tconst s8 arg1, u8 opcode, struct hppa_jit_context *ctx)\n+static void emit_call_libgcc_ll(void *func, const s8 arg0, const s8 arg1,\n+\t\tu8 opcode, bool is_signed, struct hppa_jit_context *ctx)\n {\n \tu64 func_addr;\n \n \tif (BPF_CLASS(opcode) == BPF_ALU) {\n-\t\temit_hppa64_zext32(arg0, HPPA_REG_ARG0, ctx);\n-\t\temit_hppa64_zext32(arg1, HPPA_REG_ARG1, ctx);\n+\t\tif (is_signed) {\n+\t\t\temit_hppa64_sext32(arg0, HPPA_REG_ARG0, ctx);\n+\t\t\temit_hppa64_sext32(arg1, HPPA_REG_ARG1, ctx);\n+\t\t} else {\n+\t\t\temit_hppa64_zext32(arg0, HPPA_REG_ARG0, ctx);\n+\t\t\temit_hppa64_zext32(arg1, HPPA_REG_ARG1, ctx);\n+\t\t}\n \t} else {\n \t\temit_hppa_copy(arg0, HPPA_REG_ARG0, ctx);\n \t\temit_hppa_copy(arg1, HPPA_REG_ARG1, ctx);\n@@ -600,6 +605,8 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,\n \tu8 rd = -1, rs = -1, code = insn-\u003ecode;\n \ts16 off = insn-\u003eoff;\n \ts32 imm = insn-\u003eimm;\n+\tbool is_signed;\n+\tvoid *func;\n \n \tinit_regs(\u0026rd, \u0026rs, insn, ctx);\n \n@@ -656,29 +663,39 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,\n \t\tfallthrough;\n \tcase BPF_ALU | BPF_MUL | BPF_X:\n \tcase BPF_ALU64 | BPF_MUL | BPF_X:\n-\t\temit_call_libgcc_ll(__muldi3, rd, rs, code, ctx);\n+\t\temit_call_libgcc_ll(__muldi3, rd, rs, code, false, ctx);\n \t\tif (!is64 \u0026\u0026 !aux-\u003everifier_zext)\n \t\t\temit_zext_32(rd, ctx);\n \t\tbreak;\n \tcase BPF_ALU | BPF_DIV | BPF_K:\n \tcase BPF_ALU64 | BPF_DIV | BPF_K:\n-\t\temit_imm(HPPA_REG_T1, is64 ? (s64)(s32)imm : (u32)imm, HPPA_REG_T2, ctx);\n+\t\tis_signed = (off == 1);\n+\t\temit_imm(HPPA_REG_T1,\n+\t\t\t is64 || is_signed ? (s64)(s32)imm : (u32)imm,\n+\t\t\t HPPA_REG_T2, ctx);\n \t\trs = HPPA_REG_T1;\n \t\tfallthrough;\n \tcase BPF_ALU | BPF_DIV | BPF_X:\n \tcase BPF_ALU64 | BPF_DIV | BPF_X:\n-\t\temit_call_libgcc_ll(\u0026hppa_div64, rd, rs, code, ctx);\n+\t\tis_signed = (off == 1);\n+\t\tfunc = is_signed ? \u0026hppa_sdiv64 : \u0026hppa_div64;\n+\t\temit_call_libgcc_ll(func, rd, rs, code, is_signed, ctx);\n \t\tif (!is64 \u0026\u0026 !aux-\u003everifier_zext)\n \t\t\temit_zext_32(rd, ctx);\n \t\tbreak;\n \tcase BPF_ALU | BPF_MOD | BPF_K:\n \tcase BPF_ALU64 | BPF_MOD | BPF_K:\n-\t\temit_imm(HPPA_REG_T1, is64 ? (s64)(s32)imm : (u32)imm, HPPA_REG_T2, ctx);\n+\t\tis_signed = (off == 1);\n+\t\temit_imm(HPPA_REG_T1,\n+\t\t\t is64 || is_signed ? (s64)(s32)imm : (u32)imm,\n+\t\t\t HPPA_REG_T2, ctx);\n \t\trs = HPPA_REG_T1;\n \t\tfallthrough;\n \tcase BPF_ALU | BPF_MOD | BPF_X:\n \tcase BPF_ALU64 | BPF_MOD | BPF_X:\n-\t\temit_call_libgcc_ll(\u0026hppa_div64_rem, rd, rs, code, ctx);\n+\t\tis_signed = (off == 1);\n+\t\tfunc = is_signed ? \u0026hppa_sdiv64_rem : \u0026hppa_div64_rem;\n+\t\temit_call_libgcc_ll(func, rd, rs, code, is_signed, ctx);\n \t\tif (!is64 \u0026\u0026 !aux-\u003everifier_zext)\n \t\t\temit_zext_32(rd, ctx);\n \t\tbreak;\ndiff --git a/arch/parisc/net/bpf_jit_core.c b/arch/parisc/net/bpf_jit_core.c\nindex 172770132440db..a2f93202a2ef9c 100644\n--- a/arch/parisc/net/bpf_jit_core.c\n+++ b/arch/parisc/net/bpf_jit_core.c\n@@ -190,3 +190,17 @@ u64 hppa_div64_rem(u64 div, u64 divisor)\n \tdiv64_u64_rem(div, divisor, \u0026rem);\n \treturn rem;\n }\n+\n+u64 hppa_sdiv64(u64 div, u64 divisor)\n+{\n+\ts64 sdiv = div64_s64((s64)div, (s64)divisor);\n+\n+\treturn (u64)sdiv;\n+}\n+\n+u64 hppa_sdiv64_rem(u64 div, u64 divisor)\n+{\n+\ts64 sdiv = div64_s64((s64)div, (s64)divisor);\n+\n+\treturn (u64)((s64)div - sdiv * (s64)divisor);\n+}\n"
}
2/1 2026/07/17 23:08 agent patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
{
  "EnableConfigs": [
    "BPF_JIT"
  ],
  "FocusSymbols": [
    "hppa_sdiv64",
    "hppa_sdiv64_rem",
    "emit_alu_r64",
    "emit_alu_r32",
    "emit_call_libgcc_ll"
  ],
  "Reasoning": "The patch adds support for signed division and modulo operations to the PA-RISC BPF JIT compiler. This is functional architecture-specific code that can be reached when running BPF programs on PA-RISC (which can be emulated in QEMU).",
  "WorthFuzzing": true
}

Instruction: 
You are an expert Linux kernel maintainer.
Your job is to review a provided patch series and determine
if it makes functional changes to the kernel that should be fuzzed.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively
use your code access tools to examine the actual source code and confirm any assumptions.

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).

If it modifies reachable core kernel logic, drivers, or architectures, use your code search
tools to verify the code can be executed, then return WorthFuzzing=true.

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Do not list too generic configs (we already have them enabled). Only list those that
   specifically cover the modified code. List them in the EnableConfigs output array,
   and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

Prompt: 
For your convenience, here is the diff of the changes:
commit 4399dfba6c7361e0c4ce05f5e79abdddda0243cf
Author: syz-cluster <triage@syzkaller.com>
Date:   Fri Jul 17 23:08:23 2026 +0000

    syz-cluster: applied patch under review

diff --git a/arch/parisc/net/bpf_jit.h b/arch/parisc/net/bpf_jit.h
index 8b8896959f0449..074115c93c909c 100644
--- a/arch/parisc/net/bpf_jit.h
+++ b/arch/parisc/net/bpf_jit.h
@@ -467,6 +467,8 @@ static inline u32 hppa_t21_insn(u8 opcode, u8 r2, u8 r1, u8 ext8, u8 t)
 
 u64 hppa_div64(u64 div, u64 divisor);
 u64 hppa_div64_rem(u64 div, u64 divisor);
+u64 hppa_sdiv64(u64 div, u64 divisor);
+u64 hppa_sdiv64_rem(u64 div, u64 divisor);
 
 /* Helper functions that emit HPPA instructions when possible. */
 
diff --git a/arch/parisc/net/bpf_jit_comp32.c b/arch/parisc/net/bpf_jit_comp32.c
index 5ff0cf925fe953..eea0a34a3bfee7 100644
--- a/arch/parisc/net/bpf_jit_comp32.c
+++ b/arch/parisc/net/bpf_jit_comp32.c
@@ -321,6 +321,8 @@ static void bpf_put_reg32(const s8 *reg, const s8 *src,
 extern void $$mulI(void);
 extern void $$divU(void);
 extern void $$remU(void);
+extern void $$divI(void);
+extern void $$remI(void);
 
 static void emit_call_millicode(void *func, const s8 arg0,
 		const s8 arg1, u8 opcode, struct hppa_jit_context *ctx)
@@ -562,12 +564,14 @@ static void emit_alu_i32(const s8 *dst, s32 imm,
 }
 
 static void emit_alu_r64(const s8 *dst, const s8 *src,
-			 struct hppa_jit_context *ctx, const u8 op)
+			 struct hppa_jit_context *ctx, const u8 op,
+			 bool is_signed)
 {
 	const s8 *tmp1 = regmap[TMP_REG_1];
 	const s8 *tmp2 = regmap[TMP_REG_2];
 	const s8 *rd;
 	const s8 *rs = bpf_get_reg64(src, tmp2, ctx);
+	void *func;
 
 	if (op == BPF_MOV)
 		rd = bpf_get_reg64_ref(dst, tmp1, false, ctx);
@@ -604,10 +608,12 @@ static void emit_alu_r64(const s8 *dst, const s8 *src,
 		emit_call_libgcc_ll(__muldi3, rd, rs, op, ctx);
 		break;
 	case BPF_DIV:
-		emit_call_libgcc_ll(&hppa_div64, rd, rs, op, ctx);
+		func = is_signed ? &hppa_sdiv64 : &hppa_div64;
+		emit_call_libgcc_ll(func, rd, rs, op, ctx);
 		break;
 	case BPF_MOD:
-		emit_call_libgcc_ll(&hppa_div64_rem, rd, rs, op, ctx);
+		func = is_signed ? &hppa_sdiv64_rem : &hppa_div64_rem;
+		emit_call_libgcc_ll(func, rd, rs, op, ctx);
 		break;
 	case BPF_LSH:
 		emit_call_libgcc_ll(__ashldi3, rd, rs, op, ctx);
@@ -630,7 +636,8 @@ static void emit_alu_r64(const s8 *dst, const s8 *src,
 }
 
 static void emit_alu_r32(const s8 *dst, const s8 *src,
-			 struct hppa_jit_context *ctx, const u8 op)
+			 struct hppa_jit_context *ctx, const u8 op,
+			 bool is_signed)
 {
 	const s8 *tmp1 = regmap[TMP_REG_1];
 	const s8 *tmp2 = regmap[TMP_REG_2];
@@ -666,10 +673,12 @@ static void emit_alu_r32(const s8 *dst, const s8 *src,
 		emit_call_millicode($$mulI, lo(rd), lo(rs), op, ctx);
 		break;
 	case BPF_DIV:
-		emit_call_millicode($$divU, lo(rd), lo(rs), op, ctx);
+		emit_call_millicode(is_signed ? $$divI : $$divU,
+				    lo(rd), lo(rs), op, ctx);
 		break;
 	case BPF_MOD:
-		emit_call_millicode($$remU, lo(rd), lo(rs), op, ctx);
+		emit_call_millicode(is_signed ? $$remI : $$remU,
+				    lo(rd), lo(rs), op, ctx);
 		break;
 	case BPF_LSH:
 		emit(hppa_subi(0x1f, lo(rs), HPPA_REG_T0), ctx);
@@ -1163,12 +1172,12 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,
 			emit_imm32(tmp2, imm, ctx);
 			src = tmp2;
 		}
-		emit_alu_r64(dst, src, ctx, BPF_OP(code));
+		emit_alu_r64(dst, src, ctx, BPF_OP(code), off == 1);
 		break;
 
 	/* dst = -dst */
 	case BPF_ALU64 | BPF_NEG:
-		emit_alu_r64(dst, tmp2, ctx, BPF_OP(code));
+		emit_alu_r64(dst, tmp2, ctx, BPF_OP(code), false);
 		break;
 
 	case BPF_ALU64 | BPF_MOV | BPF_K:
@@ -1211,7 +1220,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,
 			emit_imm32(tmp2, imm, ctx);
 			src = tmp2;
 		}
-		emit_alu_r32(dst, src, ctx, BPF_OP(code));
+		emit_alu_r32(dst, src, ctx, BPF_OP(code), off == 1);
 		break;
 
 	/* dst = dst OP imm */
@@ -1236,7 +1245,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,
 		 * src is ignored---choose tmp2 as a dummy register since it
 		 * is not on the stack.
 		 */
-		emit_alu_r32(dst, tmp2, ctx, BPF_OP(code));
+		emit_alu_r32(dst, tmp2, ctx, BPF_OP(code), false);
 		break;
 
 	/* dst = BSWAP##imm(dst) */
diff --git a/arch/parisc/net/bpf_jit_comp64.c b/arch/parisc/net/bpf_jit_comp64.c
index 54b0d5e25e0246..c326fa737ec8c5 100644
--- a/arch/parisc/net/bpf_jit_comp64.c
+++ b/arch/parisc/net/bpf_jit_comp64.c
@@ -502,14 +502,19 @@ static void emit_call(u64 addr, bool fixed, struct hppa_jit_context *ctx)
 	emit_hppa_copy(HPPA_REG_RET0, regmap[BPF_REG_0], ctx);
 }
 
-static void emit_call_libgcc_ll(void *func, const s8 arg0,
-		const s8 arg1, u8 opcode, struct hppa_jit_context *ctx)
+static void emit_call_libgcc_ll(void *func, const s8 arg0, const s8 arg1,
+		u8 opcode, bool is_signed, struct hppa_jit_context *ctx)
 {
 	u64 func_addr;
 
 	if (BPF_CLASS(opcode) == BPF_ALU) {
-		emit_hppa64_zext32(arg0, HPPA_REG_ARG0, ctx);
-		emit_hppa64_zext32(arg1, HPPA_REG_ARG1, ctx);
+		if (is_signed) {
+			emit_hppa64_sext32(arg0, HPPA_REG_ARG0, ctx);
+			emit_hppa64_sext32(arg1, HPPA_REG_ARG1, ctx);
+		} else {
+			emit_hppa64_zext32(arg0, HPPA_REG_ARG0, ctx);
+			emit_hppa64_zext32(arg1, HPPA_REG_ARG1, ctx);
+		}
 	} else {
 		emit_hppa_copy(arg0, HPPA_REG_ARG0, ctx);
 		emit_hppa_copy(arg1, HPPA_REG_ARG1, ctx);
@@ -600,6 +605,8 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,
 	u8 rd = -1, rs = -1, code = insn->code;
 	s16 off = insn->off;
 	s32 imm = insn->imm;
+	bool is_signed;
+	void *func;
 
 	init_regs(&rd, &rs, insn, ctx);
 
@@ -656,29 +663,39 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,
 		fallthrough;
 	case BPF_ALU | BPF_MUL | BPF_X:
 	case BPF_ALU64 | BPF_MUL | BPF_X:
-		emit_call_libgcc_ll(__muldi3, rd, rs, code, ctx);
+		emit_call_libgcc_ll(__muldi3, rd, rs, code, false, ctx);
 		if (!is64 && !aux->verifier_zext)
 			emit_zext_32(rd, ctx);
 		break;
 	case BPF_ALU | BPF_DIV | BPF_K:
 	case BPF_ALU64 | BPF_DIV | BPF_K:
-		emit_imm(HPPA_REG_T1, is64 ? (s64)(s32)imm : (u32)imm, HPPA_REG_T2, ctx);
+		is_signed = (off == 1);
+		emit_imm(HPPA_REG_T1,
+			 is64 || is_signed ? (s64)(s32)imm : (u32)imm,
+			 HPPA_REG_T2, ctx);
 		rs = HPPA_REG_T1;
 		fallthrough;
 	case BPF_ALU | BPF_DIV | BPF_X:
 	case BPF_ALU64 | BPF_DIV | BPF_X:
-		emit_call_libgcc_ll(&hppa_div64, rd, rs, code, ctx);
+		is_signed = (off == 1);
+		func = is_signed ? &hppa_sdiv64 : &hppa_div64;
+		emit_call_libgcc_ll(func, rd, rs, code, is_signed, ctx);
 		if (!is64 && !aux->verifier_zext)
 			emit_zext_32(rd, ctx);
 		break;
 	case BPF_ALU | BPF_MOD | BPF_K:
 	case BPF_ALU64 | BPF_MOD | BPF_K:
-		emit_imm(HPPA_REG_T1, is64 ? (s64)(s32)imm : (u32)imm, HPPA_REG_T2, ctx);
+		is_signed = (off == 1);
+		emit_imm(HPPA_REG_T1,
+			 is64 || is_signed ? (s64)(s32)imm : (u32)imm,
+			 HPPA_REG_T2, ctx);
 		rs = HPPA_REG_T1;
 		fallthrough;
 	case BPF_ALU | BPF_MOD | BPF_X:
 	case BPF_ALU64 | BPF_MOD | BPF_X:
-		emit_call_libgcc_ll(&hppa_div64_rem, rd, rs, code, ctx);
+		is_signed = (off == 1);
+		func = is_signed ? &hppa_sdiv64_rem : &hppa_div64_rem;
+		emit_call_libgcc_ll(func, rd, rs, code, is_signed, ctx);
 		if (!is64 && !aux->verifier_zext)
 			emit_zext_32(rd, ctx);
 		break;
diff --git a/arch/parisc/net/bpf_jit_core.c b/arch/parisc/net/bpf_jit_core.c
index 172770132440db..a2f93202a2ef9c 100644
--- a/arch/parisc/net/bpf_jit_core.c
+++ b/arch/parisc/net/bpf_jit_core.c
@@ -190,3 +190,17 @@ u64 hppa_div64_rem(u64 div, u64 divisor)
 	div64_u64_rem(div, divisor, &rem);
 	return rem;
 }
+
+u64 hppa_sdiv64(u64 div, u64 divisor)
+{
+	s64 sdiv = div64_s64((s64)div, (s64)divisor);
+
+	return (u64)sdiv;
+}
+
+u64 hppa_sdiv64_rem(u64 div, u64 divisor)
+{
+	s64 sdiv = div64_s64((s64)div, (s64)divisor);
+
+	return (u64)((s64)div - sdiv * (s64)divisor);
+}

3/2 2026/07/17 23:08 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 5537
							output: 29
							thoughts: 351

Thoughts: 
**PA-RISC BPF JIT Patch Analysis**

Okay, so I'm looking at this patch that adds signed division and modulo support (`sdiv`, `smod`) to the BPF JIT compiler, specifically for the PA-RISC architecture. The code changes are in the `arch/parisc/net/` directory, which makes it architecture-specific. Naturally, it's only going to be compiled if the kernel is configured for PA-RISC.

My first thought is about fuzzing. We typically see fuzzing on x86_64, ARM64, RISC-V, and the like. Does syzkaller even target PA-RISC? I need to check. Even if it doesn't *currently* fuzz PA-RISC, it’s still good to have the code there for someone who *does* run it on that architecture. However, I need to keep in mind the instructions for code fuzzing. There might be code paths which are impossible to reach in virtualized environments. Luckily, QEMU *does* support PA-RISC emulation (`qemu-system-hppa`). So that's not a concern.

Now I'm thinking about the necessary kernel configuration. We'll need `CONFIG_BPF_JIT` for sure, and obviously `CONFIG_PARISC`. Let me just double check the Kconfig to confirm if there are any specific PA-RISC related details for `BPF_JIT`.

4/2 2026/07/17 23:08 tool grepper
0m Args: 
{
  "Expression": "BPF_JIT",
  "PathPrefix": "arch/parisc"
}

Results: 
{
  "Output": "arch/parisc/Kconfig=2=config PARISC\n--\narch/parisc/Kconfig-72-\tselect HAVE_ARCH_TRACEHOOK\narch/parisc/Kconfig:73:\tselect HAVE_EBPF_JIT\narch/parisc/Kconfig:74:\tselect ARCH_WANT_DEFAULT_BPF_JIT\narch/parisc/Kconfig-75-\tselect HAVE_REGS_AND_STACK_ACCESS_API\n--\narch/parisc/net/Makefile-2-\narch/parisc/net/Makefile:3:obj-$(CONFIG_BPF_JIT) += bpf_jit_core.o\narch/parisc/net/Makefile-4-\narch/parisc/net/Makefile=5=ifeq ($(CONFIG_64BIT),y)\narch/parisc/net/Makefile:6:\tobj-$(CONFIG_BPF_JIT) += bpf_jit_comp64.o\narch/parisc/net/Makefile-7-else\narch/parisc/net/Makefile:8:\tobj-$(CONFIG_BPF_JIT) += bpf_jit_comp32.o\narch/parisc/net/Makefile-9-endif\n--\narch/parisc/net/bpf_jit.h-8-\narch/parisc/net/bpf_jit.h:9:#ifndef _BPF_JIT_H\narch/parisc/net/bpf_jit.h:10:#define _BPF_JIT_H\narch/parisc/net/bpf_jit.h-11-\n--\narch/parisc/net/bpf_jit.h=478=int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,\n--\narch/parisc/net/bpf_jit.h-480-\narch/parisc/net/bpf_jit.h:481:#endif /* _BPF_JIT_H */\n--\narch/parisc/net/bpf_jit_comp32.c-32- *                 +----------+ \u003c= (sp - 4 * NR_SAVED_REGISTERS\narch/parisc/net/bpf_jit_comp32.c:33: *                 |          |        - 4 * BPF_JIT_SCRATCH_REGS)\narch/parisc/net/bpf_jit_comp32.c-34- *                 |          |\n--\narch/parisc/net/bpf_jit_comp32.c=43=enum {\n--\narch/parisc/net/bpf_jit_comp32.c-54-\tBPF_R0_TEMP_LO,\narch/parisc/net/bpf_jit_comp32.c:55:\tBPF_JIT_SCRATCH_REGS,\narch/parisc/net/bpf_jit_comp32.c-56-};\n--\narch/parisc/net/bpf_jit_comp32.c-68-\narch/parisc/net/bpf_jit_comp32.c:69:#define TMP_REG_1\t(MAX_BPF_JIT_REG + 0)\narch/parisc/net/bpf_jit_comp32.c:70:#define TMP_REG_2\t(MAX_BPF_JIT_REG + 1)\narch/parisc/net/bpf_jit_comp32.c:71:#define TMP_REG_R0\t(MAX_BPF_JIT_REG + 2)\narch/parisc/net/bpf_jit_comp32.c-72-\n--\narch/parisc/net/bpf_jit_comp32.c=1476=void bpf_jit_build_prologue(struct hppa_jit_context *ctx)\n--\narch/parisc/net/bpf_jit_comp32.c-1497-\t/* make space for BPF registers on stack. */\narch/parisc/net/bpf_jit_comp32.c:1498:\tstack_adjust += BPF_JIT_SCRATCH_REGS * REG_SIZE;\narch/parisc/net/bpf_jit_comp32.c-1499-\t/* make space for BPF stack. */\n--\narch/parisc/net/bpf_jit_comp32.c-1610-\t\tif (REG_WAS_SEEN(ctx, lo(reg)))\narch/parisc/net/bpf_jit_comp32.c:1611:\t\t\temit(hppa_ldo(-REG_SIZE * (NR_SAVED_REGISTERS + BPF_JIT_SCRATCH_REGS),\narch/parisc/net/bpf_jit_comp32.c-1612-\t\t\t\tHPPA_REG_SP, lo(reg)), ctx);\n"
}
5/2 2026/07/17 23:08 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 7439
							output: 46
							thoughts: 531

Thoughts: 
**Analyzing the PA-RISC BPF JIT Compiler Patch**

Okay, so I'm looking at a patch that touches the PA-RISC architecture's BPF JIT compiler. Specifically, it seems like we're dealing with modifications to `arch/parisc/net/bpf_jit_comp32.c`, `arch/parisc/net/bpf_jit_comp64.c`, and `arch/parisc/net/bpf_jit_core.c`. The core of this seems to be the addition of `hppa_sdiv64` and `hppa_sdiv64_rem` to `bpf_jit_core.c`, plus some modifications in the 32-bit and 64-bit compilation files.

The key functions to concentrate on are: `bpf_jit_emit_insn`, `emit_alu_r64`, `emit_alu_r32`, `emit_call_libgcc_ll`, `hppa_sdiv64`, and `hppa_sdiv64_rem`. These are obviously where the new code or the altered code resides. The `BPF_JIT` config seems relevant here, naturally.

The critical question is, does this warrant fuzzing? Absolutely. It’s a functional change in the JIT compiler, and those are always good targets. Now, the potential problem is that Syzkaller, in its default setup, doesn't natively support PA-RISC fuzzing. But, wait, the notes specify that it *can* be configured if QEMU supports it. And it does. Great. It mentions something about "impossible code paths" in virtualized environments like GCE or QEMU, but since QEMU supports PA-RISC, this shouldn't be a problem.

Now, which function is the best to focus on? `bpf_jit_emit_insn` is a bit generic for the JIT compiler, but it's where the changes occur so it's probably important. `emit_alu_r64` and `emit_alu_r32` also sound like good candidates to look at. And `hppa_sdiv64` and `hppa_sdiv64_rem` sound like gold-level targeted functions because they are quite specific.

I need to nail down the exact signature of `bpf_jit_emit_insn` in `arch/parisc/net/bpf_jit_comp64.c`, to understand its inputs and outputs.

6/2 2026/07/17 23:08 tool grepper
0m Args: 
{
  "Expression": "bpf_jit_emit_insn",
  "PathPrefix": "arch/parisc/net/bpf_jit_comp64.c"
}

Results: 
{
  "Output": "arch/parisc/net/bpf_jit_comp64.c=559=static void emit_store(const s8 rd, const s8 rs, s16 off,\n--\narch/parisc/net/bpf_jit_comp64.c-596-\narch/parisc/net/bpf_jit_comp64.c:597:int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,\narch/parisc/net/bpf_jit_comp64.c-598-\t\t      bool extra_pass)\n"
}
7/2 2026/07/17 23:08 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 8737
							output: 44
							thoughts: 98

Thoughts: 
**Analyzing PA-RISC JIT Compilation for 64-bit Division**

Okay, so I need to get a handle on the 64-bit division implementation within this PA-RISC JIT compiler. I know how critical efficient division is in any BPF context, and I'm guessing there's potential for optimization here. My immediate focus needs to be on these specific functions: `hppa_sdiv64`, `hppa_sdiv64_rem`, `emit_alu_r64`, `emit_alu_r32`, and `emit_call_libgcc_ll`. They are the likely key players in how this architecture handles signed 64-bit division.

Right, so where's the best place to start? Given the context, the function `emit_alu_r64` looks like a good jumping-off point. It’s probably the lower-level function that emits the actual ALU instructions. I'll need to dig into `arch/parisc/net/bpf_jit_comp32.c`. That should give me a solid view on how 64-bit division is being lowered into the ISA. Let’s see what's actually going on in there... I'm expecting this to shed light on whether or not they are using direct instructions, library calls, or some combination of the two. Understanding that quickly will be crucial to further analysis and potential optimization, as well as finding areas where this could be inlined for efficiency or potentially improved via instruction selection.

8/2 2026/07/17 23:08 tool grepper
0m Args: 
{
  "Expression": "emit_alu_r64",
  "PathPrefix": "arch/parisc/net/bpf_jit_comp32.c"
}

Results: 
{
  "Output": "arch/parisc/net/bpf_jit_comp32.c=511=static void emit_alu_i32(const s8 *dst, s32 imm,\n--\narch/parisc/net/bpf_jit_comp32.c-565-\narch/parisc/net/bpf_jit_comp32.c:566:static void emit_alu_r64(const s8 *dst, const s8 *src,\narch/parisc/net/bpf_jit_comp32.c-567-\t\t\t struct hppa_jit_context *ctx, const u8 op,\n--\narch/parisc/net/bpf_jit_comp32.c=1125=int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,\n--\narch/parisc/net/bpf_jit_comp32.c-1174-\t\t}\narch/parisc/net/bpf_jit_comp32.c:1175:\t\temit_alu_r64(dst, src, ctx, BPF_OP(code), off == 1);\narch/parisc/net/bpf_jit_comp32.c-1176-\t\tbreak;\n--\narch/parisc/net/bpf_jit_comp32.c-1179-\tcase BPF_ALU64 | BPF_NEG:\narch/parisc/net/bpf_jit_comp32.c:1180:\t\temit_alu_r64(dst, tmp2, ctx, BPF_OP(code), false);\narch/parisc/net/bpf_jit_comp32.c-1181-\t\tbreak;\n"
}
9/2 2026/07/17 23:08 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 9652
							output: 29
							thoughts: 159

Thoughts: 
**Analyzing the Configuration Requirements**

Okay, so I'm looking at these configuration requirements. Initially, I saw `BPF_JIT` and `PARISC` listed. Hold on a second, that doesn't make sense. `PARISC` is an *architecture*, not a configurable option you toggle on or off in a configuration file like a `.config` file. I need to be more precise here. I should just list `BPF_JIT` since that's a legitimate configuration setting.

Hmm, but wait, the instructions are quite clear: "Do not list too generic configs (we already have them enabled). Only list those that specifically cover the modified code." Is `BPF_JIT` specific *enough*? Well, considering this is related to BPF JIT code, yeah, it seems appropriately targeted. It's not something broadly enabled across every system. It's directly tied to the JIT functionality.

Now, a quick sanity check. I need to make sure `BPF_JIT` isn't already enabled by default in syzbot. It usually is, but I should list it anyway to be extra sure the intention is understood. Always good to be explicit.

Right, I'll go through the configurations again to check for any other ones.

10/2 2026/07/17 23:08 tool grepper
0m Args: 
{
  "Expression": "CONFIG_",
  "PathPrefix": "arch/parisc/net/"
}

Results: 
{
  "Output": "arch/parisc/net/Makefile-2-\narch/parisc/net/Makefile:3:obj-$(CONFIG_BPF_JIT) += bpf_jit_core.o\narch/parisc/net/Makefile-4-\narch/parisc/net/Makefile:5:ifeq ($(CONFIG_64BIT),y)\narch/parisc/net/Makefile:6:\tobj-$(CONFIG_BPF_JIT) += bpf_jit_comp64.o\narch/parisc/net/Makefile-7-else\narch/parisc/net/Makefile:8:\tobj-$(CONFIG_BPF_JIT) += bpf_jit_comp32.o\narch/parisc/net/Makefile-9-endif\n--\narch/parisc/net/bpf_jit.h=25=enum {\n--\narch/parisc/net/bpf_jit.h-44-\narch/parisc/net/bpf_jit.h:45:#ifdef CONFIG_64BIT\narch/parisc/net/bpf_jit.h-46-\tHPPA_REG_TCC\t     = 3,\n--\narch/parisc/net/bpf_jit.h-57-\tHPPA_REG_T2 =\tHPPA_REG_ARG4,\narch/parisc/net/bpf_jit.h:58:#ifndef CONFIG_64BIT\narch/parisc/net/bpf_jit.h-59-\tHPPA_REG_T3 =\tHPPA_REG_ARG5,\t/* not used in 64-bit */\n--\narch/parisc/net/bpf_jit.h=65=struct hppa_jit_context {\n--\narch/parisc/net/bpf_jit.h-180-#define hppa_combt(r1, r2, target_addr, condition, nop) \\\narch/parisc/net/bpf_jit.h:181:\thppa_t11_insn(IS_ENABLED(CONFIG_64BIT) ? 0x27 : 0x20, \\\narch/parisc/net/bpf_jit.h-182-\t\tr2, r1, condition, target_addr, nop)\t\t/* combt,cond,n r1,r2,addr */\n--\narch/parisc/net/bpf_jit.h-194-#define hppa_combf(r1, r2, target_addr, condition, nop) \\\narch/parisc/net/bpf_jit.h:195:\thppa_t11_insn(IS_ENABLED(CONFIG_64BIT) ? 0x2f : 0x22, \\\narch/parisc/net/bpf_jit.h-196-\t\tr2, r1, condition, target_addr, nop)\t\t/* combf,cond,n r1,r2,addr */\n--\narch/parisc/net/bpf_jit.h-208-/* 64-bit instructions */\narch/parisc/net/bpf_jit.h:209:#ifdef CONFIG_64BIT\narch/parisc/net/bpf_jit.h-210-#define hppa64_ldd_reg(reg, b, target) \\\n--\narch/parisc/net/bpf_jit.h=365=static inline unsigned re_assemble_14(unsigned as14)\n--\narch/parisc/net/bpf_jit.h-370-\narch/parisc/net/bpf_jit.h:371:#ifdef CONFIG_64BIT\narch/parisc/net/bpf_jit.h-372-static inline unsigned re_assemble_16(unsigned as16)\n"
}
11/2 2026/07/17 23:08 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 11036
							output: 144
							thoughts: 184

Thoughts: 
**My Assessment of the PA-RISC BPF JIT Patch**

Okay, so I've been looking at this patch for the PA-RISC architecture's BPF JIT compiler. While `64BIT` is *technically* relevant due to its general nature, the core of this is definitely `BPF_JIT`. That's the one I need to focus on.

Let's break this down clearly. This patch is absolutely worth fuzzing – `WorthFuzzing: true`. The reason is solid: It's introducing new signed division and modulo operations within the PA-RISC BPF JIT compiler. This is architectural functionality that's specific to PA-RISC, and critically, *reachable* when running BPF programs on that architecture. The fact that PA-RISC can be emulated using QEMU is a huge bonus, meaning testing this is completely feasible.

The functions I need to target for deep dives are: `hppa_sdiv64`, `hppa_sdiv64_rem`, `emit_alu_r64`, `emit_alu_r32`, and `emit_call_libgcc_ll`. These are the key symbols, as they are likely where the new operations are implemented. And the enabling config, the one that makes this all possible, is `BPF_JIT`.

12/2 2026/07/17 23:08 tool set-results
0m Args: 
{
  "EnableConfigs": [
    "BPF_JIT"
  ],
  "FocusSymbols": [
    "hppa_sdiv64",
    "hppa_sdiv64_rem",
    "emit_alu_r64",
    "emit_alu_r32",
    "emit_call_libgcc_ll"
  ],
  "Reasoning": "The patch adds support for signed division and modulo operations to the PA-RISC BPF JIT compiler. This is functional architecture-specific code that can be reached when running BPF programs on PA-RISC (which can be emulated in QEMU).",
  "WorthFuzzing": true
}

Results: 
{
  "EnableConfigs": [
    "BPF_JIT"
  ],
  "FocusSymbols": [
    "hppa_sdiv64",
    "hppa_sdiv64_rem",
    "emit_alu_r64",
    "emit_alu_r32",
    "emit_call_libgcc_ll"
  ],
  "Reasoning": "The patch adds support for signed division and modulo operations to the PA-RISC BPF JIT compiler. This is functional architecture-specific code that can be reached when running BPF programs on PA-RISC (which can be emulated in QEMU).",
  "WorthFuzzing": true
}
LLM Calls Summary:
Total Calls Total Tokens Avg Tokens Total Duration (Seconds) Avg Duration (Seconds)
Tool Calls Summary:
Total Calls Total Duration (Seconds) Avg Duration (Seconds)