AI Trajectory

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "KMSANReasoning": "",
  "NeedsKMSAN": false,
  "Reasoning": "The patch only modifies KVM selftests (tools/testing/selftests/kvm/lib/riscv/processor.c) and does not make any functional changes to the core kernel, drivers, or architectures. Therefore, it does not require fuzzing.",
  "WorthFuzzing": false
}

null

{
  "PatchDiff": "commit f42f592b13f7f179df1c02b986cdd7cd73a5dcaf\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Tue Aug 11 09:17:41 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 ded5429f34483..05e20ef400eb7 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,13 @@\n \n static gva_t exception_handlers;\n \n+struct handlers {\n+\texception_handler_fn exception_handlers[NR_VECTORS][NR_EXCEPTIONS];\n+\tbool v_available;\n+\tunsigned int v_epc_capacity;\n+\tunsigned long v_epc[];\n+};\n+\n bool __vcpu_has_ext(struct kvm_vcpu *vcpu, u64 ext)\n {\n \tunsigned long value = 0;\n@@ -298,13 +305,6 @@ void vcpu_arch_dump(FILE *stream, struct kvm_vcpu *vcpu, u8 indent)\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 +348,33 @@ 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+\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+\t/*\n+\t * Record V extension availability in the handlers struct so that\n+\t * route_exception() (called from Guest context) can check it\n+\t * without relying on a host-side global variable.\n+\t */\n+\t{\n+\t\tstruct handlers *h = addr_gva2hva(vm, vm-\u003ehandlers);\n+\n+\t\th-\u003ev_available = __vcpu_has_isa_ext(vcpu, KVM_RISCV_ISA_EXT_V);\n+\t}\n \n \treturn vcpu;\n }\n@@ -408,19 +433,17 @@ void assert_on_unhandled_exception(struct kvm_vcpu *vcpu)\n \tstruct ucall uc;\n \n \tif (get_ucall(vcpu, \u0026uc) == UCALL_UNHANDLED) {\n+\t\tvcpu_dump(stderr, vcpu, 2);\n \t\tTEST_FAIL(\"Unexpected exception (vector:0x%lx, ec:0x%lx)\",\n \t\t\tuc.args[0], uc.args[1]);\n \t}\n }\n \n-struct handlers {\n-\texception_handler_fn exception_handlers[NR_VECTORS][NR_EXCEPTIONS];\n-};\n-\n void route_exception(struct pt_regs *regs)\n {\n \tstruct handlers *handlers = (struct handlers *)exception_handlers;\n-\tint vector = 0, ec;\n+\tint vector = 0;\n+\tunsigned long ec;\n \n \tec = regs-\u003ecause \u0026 ~CAUSE_IRQ_FLAG;\n \tif (ec \u003e= NR_EXCEPTIONS)\n@@ -432,6 +455,46 @@ 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 re-execute the faulting instruction.\n+\t\t *\n+\t\t * Use regs-\u003estatus (saved at exception entry) rather than\n+\t\t * reading the live CSR to avoid a TOCTOU race.\n+\t\t *\n+\t\t * Track the epc per-vCPU to avoid an infinite loop when\n+\t\t * V is disabled or the hardware rejects the VS change.\n+\t\t * Using a per-vCPU array avoids races between concurrent\n+\t\t * vCPUs that would occur with a single shared (epc, vcpu)\n+\t\t * pair.\n+\t\t */\n+\t\tif (handlers \u0026\u0026 handlers-\u003ev_available \u0026\u0026 !(regs-\u003estatus \u0026 SR_VS)) {\n+\t\t\tunsigned int vcpu_id;\n+\n+\t\t\tasm volatile(\"csrr %0, sscratch\" : \"=r\" (vcpu_id));\n+\t\t\tif (vcpu_id \u003c handlers-\u003ev_epc_capacity \u0026\u0026\n+\t\t\t    handlers-\u003ev_epc[vcpu_id] != regs-\u003eepc) {\n+\t\t\t\thandlers-\u003ev_epc[vcpu_id] = regs-\u003eepc;\n+\t\t\t\tregs-\u003estatus |= SR_VS_INITIAL;\n+\t\t\t\treturn;\n+\t\t\t}\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,9 +511,31 @@ void vcpu_init_vector_tables(struct kvm_vcpu *vcpu)\n \n void vm_init_vector_tables(struct kvm_vm *vm)\n {\n-\tvm-\u003ehandlers = __vm_alloc(vm, sizeof(struct handlers), vm-\u003epage_size,\n+\tunsigned int max_vcpu_id;\n+\tsize_t size;\n+\n+\tif (vm-\u003ehandlers)\n+\t\treturn;\n+\n+\tmax_vcpu_id = kvm_check_cap(KVM_CAP_MAX_VCPU_ID);\n+\tif (max_vcpu_id == 0)\n+\t\tmax_vcpu_id = 512;\n+\n+\t/*\n+\t * vcpu_id may be sparse and ranges from 0 to KVM_CAP_MAX_VCPU_ID\n+\t * (which can be much larger than KVM_CAP_MAX_VCPUS), so size the\n+\t * per-vCPU epc array accordingly.\n+\t */\n+\tsize = sizeof(struct handlers) + (max_vcpu_id + 1) * sizeof(unsigned long);\n+\tvm-\u003ehandlers = __vm_alloc(vm, size, vm-\u003epage_size,\n \t\t\t\t  MEM_REGION_DATA);\n \n+\t{\n+\t\tstruct handlers *h = addr_gva2hva(vm, vm-\u003ehandlers);\n+\n+\t\th-\u003ev_epc_capacity = max_vcpu_id + 1;\n+\t}\n+\n \t*(gva_t *)addr_gva2hva(vm, (gva_t)(\u0026exception_handlers)) = vm-\u003ehandlers;\n }\n \n"
}

best-expensive

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch only modifies KVM selftests (tools/testing/selftests/kvm/lib/riscv/processor.c) and does not make any functional changes to the core kernel, drivers, or architectures. Therefore, it does not require fuzzing.",
  "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).
- Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers (e.g., mlxsw, pds_core, qed,
  ionic, amdgpu) that require physical PCIe hardware cards not emulated in standard QEMU.
- Driver .remove, .shutdown, or pci_unregister_driver teardown callbacks (e.g., igb_remove)
  that are executed only during PCI hot-unplug or sysfs driver unbind operations.

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.
   Prefer non-static, non-inlined API entrypoint functions over internal static helper functions
   (which are inlined by the compiler and do not have distinct symbol addresses).
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.
   Also check "depends on" lines in Kconfig to include any non-standard parent subsystem configs
   needed for Kbuild to compile the code statically into vmlinux. 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 f42f592b13f7f179df1c02b986cdd7cd73a5dcaf
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Aug 11 09:17:41 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 ded5429f34483..05e20ef400eb7 100644
--- a/tools/testing/selftests/kvm/lib/riscv/processor.c
+++ b/tools/testing/selftests/kvm/lib/riscv/processor.c
@@ -17,6 +17,13 @@
 
 static gva_t exception_handlers;
 
+struct handlers {
+	exception_handler_fn exception_handlers[NR_VECTORS][NR_EXCEPTIONS];
+	bool v_available;
+	unsigned int v_epc_capacity;
+	unsigned long v_epc[];
+};
+
 bool __vcpu_has_ext(struct kvm_vcpu *vcpu, u64 ext)
 {
 	unsigned long value = 0;
@@ -298,13 +305,6 @@ void vcpu_arch_dump(FILE *stream, struct kvm_vcpu *vcpu, u8 indent)
 		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 +348,33 @@ 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);
+
+	/*
+	 * 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);
+
+	/*
+	 * Record V extension availability in the handlers struct so that
+	 * route_exception() (called from Guest context) can check it
+	 * without relying on a host-side global variable.
+	 */
+	{
+		struct handlers *h = addr_gva2hva(vm, vm->handlers);
+
+		h->v_available = __vcpu_has_isa_ext(vcpu, KVM_RISCV_ISA_EXT_V);
+	}
 
 	return vcpu;
 }
@@ -408,19 +433,17 @@ void assert_on_unhandled_exception(struct kvm_vcpu *vcpu)
 	struct ucall uc;
 
 	if (get_ucall(vcpu, &uc) == UCALL_UNHANDLED) {
+		vcpu_dump(stderr, vcpu, 2);
 		TEST_FAIL("Unexpected exception (vector:0x%lx, ec:0x%lx)",
 			uc.args[0], uc.args[1]);
 	}
 }
 
-struct handlers {
-	exception_handler_fn exception_handlers[NR_VECTORS][NR_EXCEPTIONS];
-};
-
 void route_exception(struct pt_regs *regs)
 {
 	struct handlers *handlers = (struct handlers *)exception_handlers;
-	int vector = 0, ec;
+	int vector = 0;
+	unsigned long ec;
 
 	ec = regs->cause & ~CAUSE_IRQ_FLAG;
 	if (ec >= NR_EXCEPTIONS)
@@ -432,6 +455,46 @@ 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 re-execute the faulting instruction.
+		 *
+		 * Use regs->status (saved at exception entry) rather than
+		 * reading the live CSR to avoid a TOCTOU race.
+		 *
+		 * Track the epc per-vCPU to avoid an infinite loop when
+		 * V is disabled or the hardware rejects the VS change.
+		 * Using a per-vCPU array avoids races between concurrent
+		 * vCPUs that would occur with a single shared (epc, vcpu)
+		 * pair.
+		 */
+		if (handlers && handlers->v_available && !(regs->status & SR_VS)) {
+			unsigned int vcpu_id;
+
+			asm volatile("csrr %0, sscratch" : "=r" (vcpu_id));
+			if (vcpu_id < handlers->v_epc_capacity &&
+			    handlers->v_epc[vcpu_id] != regs->epc) {
+				handlers->v_epc[vcpu_id] = regs->epc;
+				regs->status |= SR_VS_INITIAL;
+				return;
+			}
+		}
+	}
+
 	if (handlers && handlers->exception_handlers[vector][ec])
 		return handlers->exception_handlers[vector][ec](regs);
 
@@ -448,9 +511,31 @@ void vcpu_init_vector_tables(struct kvm_vcpu *vcpu)
 
 void vm_init_vector_tables(struct kvm_vm *vm)
 {
-	vm->handlers = __vm_alloc(vm, sizeof(struct handlers), vm->page_size,
+	unsigned int max_vcpu_id;
+	size_t size;
+
+	if (vm->handlers)
+		return;
+
+	max_vcpu_id = kvm_check_cap(KVM_CAP_MAX_VCPU_ID);
+	if (max_vcpu_id == 0)
+		max_vcpu_id = 512;
+
+	/*
+	 * vcpu_id may be sparse and ranges from 0 to KVM_CAP_MAX_VCPU_ID
+	 * (which can be much larger than KVM_CAP_MAX_VCPUS), so size the
+	 * per-vCPU epc array accordingly.
+	 */
+	size = sizeof(struct handlers) + (max_vcpu_id + 1) * sizeof(unsigned long);
+	vm->handlers = __vm_alloc(vm, size, vm->page_size,
 				  MEM_REGION_DATA);
 
+	{
+		struct handlers *h = addr_gva2hva(vm, vm->handlers);
+
+		h->v_epc_capacity = max_vcpu_id + 1;
+	}
+
 	*(gva_t *)addr_gva2hva(vm, (gva_t)(&exception_handlers)) = vm->handlers;
 }
 

gemini-3.1-pro-preview

null

null

							input: 4010
							output: 87
							thoughts: 458
						

**Patch Analysis for Fuzzing Eligibility**

Okay, let's break this down. My initial task is to decide if this patch introduces functional changes in the kernel that warrant fuzzing. The patch modifies `tools/testing/selftests/kvm/lib/riscv/processor.c`. My immediate thought is, "Wait, this is a *selftest* file!"

The instructions explicitly state exemptions from fuzzing if the patch concerns things like documentation, Kconfig files, code comments, decorative changes such as logging or tracepoints, or changes to non-functional constants. Selftests aren't *explicitly* listed, but they seem to fit the spirit of exclusion, given they aren't part of core kernel logic, drivers, or architectures, as the instructions stipulate should be checked for executable code, and therefore warrant fuzzing.

My logic flows like this: "If core kernel logic, drivers, or architectures are modified, then code execution verification using search tools, and fuzzing must be employed. But this is just a test file." Since it touches only `tools/testing/selftests/kvm/lib/riscv/processor.c`, it's isolated. Let me just confirm that this is the only file that is affected. Double checking the diff, yes, that's the only one. So, my conclusion: this is purely a change to KVM selftests. No core kernel logic is altered.

Therefore, because this change is limited to a selftest, it doesn't represent a functional change to the kernel that I need to worry about fuzzing. I'm going to set `WorthFuzzing=false`. Just to be absolutely sure, I'm checking the path again: `tools/testing/selftests/kvm/lib/riscv/processor.c`. Yep, selftest.

{
  "EnableConfigs": [],
  "FocusSymbols": [],
  "Reasoning": "The patch only modifies KVM selftests (tools/testing/selftests/kvm/lib/riscv/processor.c) and does not make any functional changes to the core kernel, drivers, or architectures. Therefore, it does not require fuzzing.",
  "WorthFuzzing": false
}

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch only modifies KVM selftests (tools/testing/selftests/kvm/lib/riscv/processor.c) and does not make any functional changes to the core kernel, drivers, or architectures. Therefore, it does not require fuzzing.",
  "WorthFuzzing": false
}

{
  "WorthFuzzing": false
}

null