AI Trajectory

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch only modifies KVM selftests (tools/testing/selftests/), which are userspace test programs and do not change any functional kernel code that can be fuzzed.",
  "WorthFuzzing": false
}

null

{
  "PatchDiff": "commit 898f65f820acbf4e6a29f2cc91249cf5b8584476\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Wed Jul 22 06:38:08 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/tools/testing/selftests/kvm/lib/riscv/processor.c b/tools/testing/selftests/kvm/lib/riscv/processor.c\nindex ded5429f34483d..62efd07e5639d0 100644\n--- a/tools/testing/selftests/kvm/lib/riscv/processor.c\n+++ b/tools/testing/selftests/kvm/lib/riscv/processor.c\n@@ -17,6 +17,9 @@\n \n static gva_t exception_handlers;\n \n+/* True if KVM allows the Guest to use the V (vector) extension */\n+static bool v_available;\n+\n bool __vcpu_has_ext(struct kvm_vcpu *vcpu, u64 ext)\n {\n \tunsigned long value = 0;\n@@ -297,14 +300,6 @@ void vcpu_arch_dump(FILE *stream, struct kvm_vcpu *vcpu, u8 indent)\n \t\t\" T3: 0x%016lx   T4: 0x%016lx T5: 0x%016lx T6: 0x%016lx\\n\",\n \t\tcore.regs.t3, core.regs.t4, core.regs.t5, core.regs.t6);\n }\n-\n-static void __aligned(16) guest_unexp_trap(void)\n-{\n-\tsbi_ecall(KVM_RISCV_SELFTESTS_SBI_EXT,\n-\t\t  KVM_RISCV_SELFTESTS_SBI_UNEXP,\n-\t\t  0, 0, 0, 0, 0, 0);\n-}\n-\n void vcpu_arch_set_entry_point(struct kvm_vcpu *vcpu, void *guest_code)\n {\n \tvcpu_set_reg(vcpu, RISCV_CORE_REG(regs.pc), (unsigned long)guest_code);\n@@ -348,8 +343,23 @@ struct kvm_vcpu *vm_arch_vcpu_add(struct kvm_vm *vm, u32 vcpu_id)\n \t/* Setup sscratch for guest_get_vcpuid() */\n \tvcpu_set_reg(vcpu, RISCV_GENERAL_CSR_REG(sscratch), vcpu_id);\n \n-\t/* Setup default exception vector of guest */\n-\tvcpu_set_reg(vcpu, RISCV_GENERAL_CSR_REG(stvec), (unsigned long)guest_unexp_trap);\n+\t/*\n+\t * Enable the V (vector) extension in KVM so that the compiler can\n+\t * safely generate vector instructions (e.g. via -O2 auto-\n+\t * vectorization). Silently ignore errors; the test will still work\n+\t * without V.\n+\t */\n+\t__vcpu_set_reg(vcpu, RISCV_ISA_EXT_REG(KVM_RISCV_ISA_EXT_V), 1);\n+\tv_available = __vcpu_has_isa_ext(vcpu, KVM_RISCV_ISA_EXT_V);\n+\n+\t/*\n+\t * Use the full exception vector table (which provides lazy V\n+\t * extension enablement for EXC_INST_ILLEGAL in route_exception)\n+\t * as the default exception handler. vm_init_vector_tables() is\n+\t * idempotent; tests that call it again will get a no-op.\n+\t */\n+\tvm_init_vector_tables(vm);\n+\tvcpu_init_vector_tables(vcpu);\n \n \treturn vcpu;\n }\n@@ -432,6 +442,33 @@ void route_exception(struct pt_regs *regs)\n \t\tec = 0;\n \t}\n \n+\t/*\n+\t * Handle V (vector) extension lazy enablement before any\n+\t * registered handler. The compiler's default march may include\n+\t * V, and auto-vectorization generates vector instructions that\n+\t * trigger EXC_INST_ILLEGAL when VS (Vector Status) in sstatus\n+\t * is Off. Enable VS to Initial and re-execute the faulting\n+\t * instruction, mimicking what a real OS kernel does.\n+\t *\n+\t * This check runs before any test-registered handler, so tests\n+\t * that install their own EXC_INST_ILLEGAL handler (e.g.\n+\t * sbi_pmu_test) are not affected.\n+\t */\n+\tif (!(regs-\u003ecause \u0026 CAUSE_IRQ_FLAG) \u0026\u0026 ec == EXC_INST_ILLEGAL) {\n+\t\t/*\n+\t\t * If KVM supports the V extension for this Guest and VS\n+\t\t * (Vector Status) is Off in the saved sstatus, set it to\n+\t\t * Initial and sret to re-execute the faulting instruction.\n+\t\t * Use regs-\u003estatus (saved at exception entry) rather than\n+\t\t * reading the live CSR to avoid a TOCTOU race with nested\n+\t\t * exceptions.\n+\t\t */\n+\t\tif (v_available \u0026\u0026 !(regs-\u003estatus \u0026 SR_VS)) {\n+\t\t\tregs-\u003estatus |= SR_VS_INITIAL;\n+\t\t\treturn;\n+\t\t}\n+\t}\n+\n \tif (handlers \u0026\u0026 handlers-\u003eexception_handlers[vector][ec])\n \t\treturn handlers-\u003eexception_handlers[vector][ec](regs);\n \n@@ -448,6 +485,9 @@ void vcpu_init_vector_tables(struct kvm_vcpu *vcpu)\n \n void vm_init_vector_tables(struct kvm_vm *vm)\n {\n+\tif (vm-\u003ehandlers)\n+\t\treturn;\n+\n \tvm-\u003ehandlers = __vm_alloc(vm, sizeof(struct handlers), vm-\u003epage_size,\n \t\t\t\t  MEM_REGION_DATA);\n \n"
}

best-expensive

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch only modifies KVM selftests (tools/testing/selftests/), which are userspace test programs and do not change any functional kernel code that can be fuzzed.",
  "WorthFuzzing": false
}

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.

For your convenience, here is the diff of the changes:
commit 898f65f820acbf4e6a29f2cc91249cf5b8584476
Author: syz-cluster <triage@syzkaller.com>
Date:   Wed Jul 22 06:38:08 2026 +0000

    syz-cluster: applied patch under review

diff --git a/tools/testing/selftests/kvm/lib/riscv/processor.c b/tools/testing/selftests/kvm/lib/riscv/processor.c
index ded5429f34483d..62efd07e5639d0 100644
--- a/tools/testing/selftests/kvm/lib/riscv/processor.c
+++ b/tools/testing/selftests/kvm/lib/riscv/processor.c
@@ -17,6 +17,9 @@
 
 static gva_t exception_handlers;
 
+/* True if KVM allows the Guest to use the V (vector) extension */
+static bool v_available;
+
 bool __vcpu_has_ext(struct kvm_vcpu *vcpu, u64 ext)
 {
 	unsigned long value = 0;
@@ -297,14 +300,6 @@ void vcpu_arch_dump(FILE *stream, struct kvm_vcpu *vcpu, u8 indent)
 		" T3: 0x%016lx   T4: 0x%016lx T5: 0x%016lx T6: 0x%016lx\n",
 		core.regs.t3, core.regs.t4, core.regs.t5, core.regs.t6);
 }
-
-static void __aligned(16) guest_unexp_trap(void)
-{
-	sbi_ecall(KVM_RISCV_SELFTESTS_SBI_EXT,
-		  KVM_RISCV_SELFTESTS_SBI_UNEXP,
-		  0, 0, 0, 0, 0, 0);
-}
-
 void vcpu_arch_set_entry_point(struct kvm_vcpu *vcpu, void *guest_code)
 {
 	vcpu_set_reg(vcpu, RISCV_CORE_REG(regs.pc), (unsigned long)guest_code);
@@ -348,8 +343,23 @@ struct kvm_vcpu *vm_arch_vcpu_add(struct kvm_vm *vm, u32 vcpu_id)
 	/* Setup sscratch for guest_get_vcpuid() */
 	vcpu_set_reg(vcpu, RISCV_GENERAL_CSR_REG(sscratch), vcpu_id);
 
-	/* Setup default exception vector of guest */
-	vcpu_set_reg(vcpu, RISCV_GENERAL_CSR_REG(stvec), (unsigned long)guest_unexp_trap);
+	/*
+	 * Enable the V (vector) extension in KVM so that the compiler can
+	 * safely generate vector instructions (e.g. via -O2 auto-
+	 * vectorization). Silently ignore errors; the test will still work
+	 * without V.
+	 */
+	__vcpu_set_reg(vcpu, RISCV_ISA_EXT_REG(KVM_RISCV_ISA_EXT_V), 1);
+	v_available = __vcpu_has_isa_ext(vcpu, KVM_RISCV_ISA_EXT_V);
+
+	/*
+	 * Use the full exception vector table (which provides lazy V
+	 * extension enablement for EXC_INST_ILLEGAL in route_exception)
+	 * as the default exception handler. vm_init_vector_tables() is
+	 * idempotent; tests that call it again will get a no-op.
+	 */
+	vm_init_vector_tables(vm);
+	vcpu_init_vector_tables(vcpu);
 
 	return vcpu;
 }
@@ -432,6 +442,33 @@ void route_exception(struct pt_regs *regs)
 		ec = 0;
 	}
 
+	/*
+	 * Handle V (vector) extension lazy enablement before any
+	 * registered handler. The compiler's default march may include
+	 * V, and auto-vectorization generates vector instructions that
+	 * trigger EXC_INST_ILLEGAL when VS (Vector Status) in sstatus
+	 * is Off. Enable VS to Initial and re-execute the faulting
+	 * instruction, mimicking what a real OS kernel does.
+	 *
+	 * This check runs before any test-registered handler, so tests
+	 * that install their own EXC_INST_ILLEGAL handler (e.g.
+	 * sbi_pmu_test) are not affected.
+	 */
+	if (!(regs->cause & CAUSE_IRQ_FLAG) && ec == EXC_INST_ILLEGAL) {
+		/*
+		 * If KVM supports the V extension for this Guest and VS
+		 * (Vector Status) is Off in the saved sstatus, set it to
+		 * Initial and sret to re-execute the faulting instruction.
+		 * Use regs->status (saved at exception entry) rather than
+		 * reading the live CSR to avoid a TOCTOU race with nested
+		 * exceptions.
+		 */
+		if (v_available && !(regs->status & SR_VS)) {
+			regs->status |= SR_VS_INITIAL;
+			return;
+		}
+	}
+
 	if (handlers && handlers->exception_handlers[vector][ec])
 		return handlers->exception_handlers[vector][ec](regs);
 
@@ -448,6 +485,9 @@ void vcpu_init_vector_tables(struct kvm_vcpu *vcpu)
 
 void vm_init_vector_tables(struct kvm_vm *vm)
 {
+	if (vm->handlers)
+		return;
+
 	vm->handlers = __vm_alloc(vm, sizeof(struct handlers), vm->page_size,
 				  MEM_REGION_DATA);
 

gemini-3.1-pro-preview

null

null

							input: 3111
							output: 70
							thoughts: 253
						

**WorthFuzzing=false - Selftest Modification**

Okay, so I'm looking at this patch and it's modifying `tools/testing/selftests/kvm/lib/riscv/processor.c`. Right away, this jumps out to me as a selftest file, not actual kernel code. The prompt specifically says "Return WorthFuzzing=false if the patch only contains modifications to Documentation/, Kconfig files, or code comments." It doesn't explicitly *mention* selftests, but the spirit of that rule applies here. These selftests aren't part of the core kernel that Syzkaller fuzzes; Syzkaller's job is the kernel itself.

Let me just double-check, though, make sure nothing else got touched in the diff. Nope, just the one file. Now I'm recalling the prompt: "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." This definitely *doesn't* fit that description. Selftests are userspace tools, independent from the kernel, and exist to validate their operation separately.

Therefore, because this is purely a selftest modification, and doesn't impact reachable core kernel logic, I'm going to return `WorthFuzzing=false`.

{
  "EnableConfigs": [],
  "FocusSymbols": [],
  "Reasoning": "The patch only modifies KVM selftests (tools/testing/selftests/), which are userspace test programs and do not change any functional kernel code that can be fuzzed.",
  "WorthFuzzing": false
}

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch only modifies KVM selftests (tools/testing/selftests/), which are userspace test programs and do not change any functional kernel code that can be fuzzed.",
  "WorthFuzzing": false
}