AI Trajectory

null

{
  "EnableConfigs": null,
  "FocusSymbols": [
    "__do_once_sleepable_done"
  ],
  "KMSANReasoning": "The patch modifies the `__do_once_sleepable_done` function in `lib/once.c` to use `once_disable_jump` instead of `static_branch_disable`. This is related to the internal implementation of the `DO_ONCE` macro and static keys, likely to handle module unloading or deferred static branch disabling correctly. This change does not introduce any new data structures, memory allocations, or user-space copies. There is no risk of uninitialized memory usage or info-leaks. Any potential bugs introduced would be related to static keys, locking, or module state, which are covered by standard kernel debugging tools and KASAN/LOCKDEP, not KMSAN.",
  "NeedsKMSAN": false,
  "Reasoning": "The patch modifies `__do_once_sleepable_done` in `lib/once.c` to defer the static branch disable operation to a workqueue using `once_disable_jump`. This is a functional change in a core kernel primitive used by `DO_ONCE_SLEEPABLE` and `get_random_sleepable_once`, which are reachable during network connection setup (e.g., `__inet_hash_connect`). It is worth fuzzing to ensure the deferred workqueue execution does not introduce regressions or race conditions.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit c57654f24eaa6a6811bd8a3d9cceef2d7e2b2b7c\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Tue Aug 25 14:47:11 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/lib/once.c b/lib/once.c\nindex d801bfa945e63..0a0a919156e05 100644\n--- a/lib/once.c\n+++ b/lib/once.c\n@@ -93,6 +93,6 @@ void __do_once_sleepable_done(bool *done, struct static_key_true *once_key,\n {\n \t*done = true;\n \tmutex_unlock(\u0026once_mutex);\n-\tstatic_branch_disable(once_key);\n+\tonce_disable_jump(once_key, mod);\n }\n EXPORT_SYMBOL(__do_once_sleepable_done);\n"
}

best-expensive

null

{
  "EnableConfigs": null,
  "FocusSymbols": [
    "__do_once_sleepable_done"
  ],
  "Reasoning": "The patch modifies `__do_once_sleepable_done` in `lib/once.c` to defer the static branch disable operation to a workqueue using `once_disable_jump`. This is a functional change in a core kernel primitive used by `DO_ONCE_SLEEPABLE` and `get_random_sleepable_once`, which are reachable during network connection setup (e.g., `__inet_hash_connect`). It is worth fuzzing to ensure the deferred workqueue execution does not introduce regressions or race conditions.",
  "WorthFuzzing": true
}

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 c57654f24eaa6a6811bd8a3d9cceef2d7e2b2b7c
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Aug 25 14:47:11 2026 +0000

    syz-cluster: applied patch under review

diff --git a/lib/once.c b/lib/once.c
index d801bfa945e63..0a0a919156e05 100644
--- a/lib/once.c
+++ b/lib/once.c
@@ -93,6 +93,6 @@ void __do_once_sleepable_done(bool *done, struct static_key_true *once_key,
 {
 	*done = true;
 	mutex_unlock(&once_mutex);
-	static_branch_disable(once_key);
+	once_disable_jump(once_key, mod);
 }
 EXPORT_SYMBOL(__do_once_sleepable_done);

gemini-3.1-pro-preview

null

null

							input: 1954
							output: 30
							thoughts: 79
						

**Analyzing the 'once' Code Modification**

Okay, so I'm looking at this patch and it's got a pretty straightforward change in `lib/once.c`. Specifically, it's swapping out `static_branch_disable(once_key);` with `once_disable_jump(once_key, mod);` within the `__do_once_sleepable_done` function. This suggests a shift in how we're handling the "once" execution mechanism, presumably related to disabling it after the initial run. Naturally, my immediate instinct is to dig into `lib/once.c` and figure out *exactly* what `once_disable_jump` is doing. I need to understand the implications of this new function and how it differs from the original `static_branch_disable`. Is it more efficient, more flexible, potentially tied to a specific hardware feature, or maybe it is part of a bigger project? The `mod` variable also piques my interest; where is that coming from, and what's its role in all this? Need to drill into that. Time to get into the details and work through it.

{
  "Expression": "once_disable_jump",
  "PathPrefix": "lib/once.c"
}

{
  "Output": "lib/once.c=14=static void once_deferred(struct work_struct *w)\n--\nlib/once.c-24-\nlib/once.c:25:static void once_disable_jump(struct static_key_true *key, struct module *mod)\nlib/once.c-26-{\n--\nlib/once.c=60=void __do_once_done(bool *done, struct static_key_true *once_key,\n--\nlib/once.c-65-\tspin_unlock_irqrestore(\u0026once_lock, *flags);\nlib/once.c:66:\tonce_disable_jump(once_key, mod);\nlib/once.c-67-}\n--\nlib/once.c=90=void __do_once_sleepable_done(bool *done, struct static_key_true *once_key,\n--\nlib/once.c-95-\tmutex_unlock(\u0026once_mutex);\nlib/once.c:96:\tonce_disable_jump(once_key, mod);\nlib/once.c-97-}\n"
}

gemini-3.1-pro-preview

null

null

							input: 2581
							output: 32
							thoughts: 30
						

Here's my take on the thought process, summarized as you requested:

**Deconstructing `once_disable_jump`**

Okay, so I'm looking at `once_disable_jump` and my first thought is, "Right, it's a `static` function, and it lives in `lib/once.c`." That tells me a few things immediately. It's internal to that compilation unit, probably part of a larger mechanism within that library. Static functions are often used for implementation details, helper functions that aren't intended for external use. Now, the crucial part is to dig into *what* it actually does. I need to understand its role within the larger `once` system. Time to dive into the code and see how it works!

{
  "File": "lib/once.c",
  "FirstLine": 20,
  "LineCount": 40
}

{
  "Contents": "  20:\t\tstatic_branch_disable(work-\u003ekey);\n  21:\t\tmodule_put(work-\u003emodule);\n  22:\t\tkfree(work);\n  23:\t}\n  24:\t\n  25:\tstatic void once_disable_jump(struct static_key_true *key, struct module *mod)\n  26:\t{\n  27:\t\tstruct once_work *w;\n  28:\t\n  29:\t\tw = kmalloc_obj(*w, GFP_ATOMIC);\n  30:\t\tif (!w)\n  31:\t\t\treturn;\n  32:\t\n  33:\t\tINIT_WORK(\u0026w-\u003ework, once_deferred);\n  34:\t\tw-\u003ekey = key;\n  35:\t\tw-\u003emodule = mod;\n  36:\t\t__module_get(mod);\n  37:\t\tschedule_work(\u0026w-\u003ework);\n  38:\t}\n  39:\t\n  40:\tstatic DEFINE_SPINLOCK(once_lock);\n  41:\t\n  42:\tbool __do_once_start(bool *done, unsigned long *flags)\n  43:\t\t__acquires(once_lock)\n  44:\t{\n  45:\t\tspin_lock_irqsave(\u0026once_lock, *flags);\n  46:\t\tif (*done) {\n  47:\t\t\tspin_unlock_irqrestore(\u0026once_lock, *flags);\n  48:\t\t\t/* Keep sparse happy by restoring an even lock count on\n  49:\t\t\t * this lock. In case we return here, we don't call into\n  50:\t\t\t * __do_once_done but return early in the DO_ONCE() macro.\n  51:\t\t\t */\n  52:\t\t\t__acquire(once_lock);\n  53:\t\t\treturn false;\n  54:\t\t}\n  55:\t\n  56:\t\treturn true;\n  57:\t}\n  58:\tEXPORT_SYMBOL(__do_once_start);\n  59:\t\n"
}

gemini-3.1-pro-preview

null

null

							input: 3318
							output: 29
							thoughts: 176
						

**Analyzing the Change to `__do_once_sleepable_done`**

Okay, so the change is in `__do_once_sleepable_done`. They've swapped out `static_branch_disable(once_key)` for `once_disable_jump(once_key, mod)`. This is interesting; it looks like they're deferring the jump label update to a workqueue. The goal is likely to avoid sleeping or blocking in certain contexts, or perhaps they're trying to resolve some lockdep issues.

Wait a minute, `__do_once_sleepable_done` is tied to `DO_ONCE_SLEEPABLE`, right? Considering its association with `DO_ONCE_SLEEPABLE`, should this be a target for fuzzing? Hmmm, it's a fundamental kernel primitive. Fuzzing it directly might not be the most effective strategy since `DO_ONCE` and `DO_ONCE_SLEEPABLE` are used so extensively throughout the kernel. It would likely produce broad results.

I'm better off checking where `__do_once_sleepable_done` is being used to get a better sense of the scope of the potential impact.

{
  "Expression": "__do_once_sleepable_done",
  "PathPrefix": ""
}

{
  "Output": "include/linux/once.h=16=bool __do_once_sleepable_start(bool *done);\ninclude/linux/once.h:17:void __do_once_sleepable_done(bool *done, struct static_key_true *once_key,\ninclude/linux/once.h-18-\t\t\t      struct module *mod);\n--\ninclude/linux/once.h-72-\t\t\t\tfunc(__VA_ARGS__);\t\t\t\t\\\ninclude/linux/once.h:73:\t\t\t\t__do_once_sleepable_done(\u0026___done, \u0026___once_key,\\\ninclude/linux/once.h-74-\t\t\t\t\t\t    THIS_MODULE);\t\t\\\n--\nlib/once.c=88=EXPORT_SYMBOL(__do_once_sleepable_start);\nlib/once.c-89-\nlib/once.c:90:void __do_once_sleepable_done(bool *done, struct static_key_true *once_key,\nlib/once.c-91-\t\t\t struct module *mod)\n--\nlib/once.c-97-}\nlib/once.c:98:EXPORT_SYMBOL(__do_once_sleepable_done);\n"
}

gemini-3.1-pro-preview

null

null

							input: 4076
							output: 26
							thoughts: 132
						

**Fuzzing the `static_branch_disable` Workqueue Deferral**

Okay, so we're looking at a change that's essentially moving the `static_branch_disable` functionality to a workqueue. It's a fundamental change within the kernel itself, so, yes, absolutely, this warrants fuzzing. We need to make sure this doesn't introduce any subtle regressions or issues.

My immediate thought is, let's target `__do_once_sleepable_done`. That seems like a key symbol related to the "once" infrastructure, and based on my experience, a change like this could potentially interact with it in interesting ways. Wait a minute, `__do_once_sleepable_done` *is* a core kernel function. It lives in `lib/once.c`.

Let me see if there are any specific kernel configurations that might be relevant. Hmm, looks like we don't need any special config flags to enable or disable it; it seems to be built in by default. Excellent. I'll jump over to the `lib/Makefile` to confirm `once.o` is always built, ensuring it is always part of our attack surface for fuzzing.

{
  "Expression": "once\\.o",
  "PathPrefix": "lib/Makefile"
}

{
  "Output": "lib/Makefile=55=obj-y += bcd.o sort.o parser.o debug_locks.o random32.o \\\n--\nlib/Makefile-59-\t percpu-refcount.o rhashtable.o base64.o \\\nlib/Makefile:60:\t once.o refcount.o rcuref.o usercopy.o errseq.o bucket_locks.o \\\nlib/Makefile-61-\t generic-radix-tree.o bitmap-str.o\n"
}

gemini-3.1-pro-preview

null

null

							input: 4621
							output: 28
							thoughts: 225
						

**Fuzzing Potential: `once.o` and `__do_once_sleepable_done`**

Okay, so `once.o` is consistently built, that's a good starting point. My initial thought is to pinpoint a specific function to focus the fuzzing on. Right, `__do_once_sleepable_done` looks interesting, especially since it's an exported symbol. Is this small code change - replacing `static_branch_disable` with `once_disable_jump` - even worth fuzzing? On the face of it, it appears functionally minor, but this is a core primitive we're talking about here.

Hmm, `once_disable_jump` is also a function, but static. That doesn't look promising for direct fuzzing, though the interaction with the non-static symbol is still intriguing. Given the change and that the target is a core primitive, I think the effort is justified.

Is `__do_once_sleepable_done` a hot-path function? That's the real question. `DO_ONCE_SLEEPABLE` suggests one-time initialization, so it is not a hot path after the first execution. But, the first time it *is* called, this function is executed. Therefore, that initial execution path is the critical one.

I'll flag it as WorthFuzzing=true, with FocusSymbols=["__do_once_sleepable_done"]. Now let's see exactly where `DO_ONCE_SLEEPABLE` is used to get more context.

{
  "Expression": "DO_ONCE_SLEEPABLE",
  "PathPrefix": ""
}

{
  "Output": "fs/resctrl/rdtgroup.c=3171=static int rdt_get_tree(struct fs_context *fc)\n--\nfs/resctrl/rdtgroup.c-3179-\nfs/resctrl/rdtgroup.c:3180:\tDO_ONCE_SLEEPABLE(resctrl_arch_pre_mount);\nfs/resctrl/rdtgroup.c-3181-\n--\ninclude/linux/once.h=17=void __do_once_sleepable_done(bool *done, struct static_key_true *once_key,\n--\ninclude/linux/once.h-63-/* Variant of DO_ONCE() for process/sleepable contexts. */\ninclude/linux/once.h:64:#define DO_ONCE_SLEEPABLE(func, ...)\t\t\t\t\t\t\\\ninclude/linux/once.h-65-\t({\t\t\t\t\t\t\t\t\t\\\n--\ninclude/linux/once.h-83-#define get_random_sleepable_once(buf, nbytes)\t\t\t\t     \\\ninclude/linux/once.h:84:\tDO_ONCE_SLEEPABLE(get_random_bytes, (buf), (nbytes))\ninclude/linux/once.h-85-\n--\nlib/once.c=72=bool __do_once_sleepable_start(bool *done)\n--\nlib/once.c-79-\t\t * this mutex. In case we return here, we don't call into\nlib/once.c:80:\t\t * __do_once_done but return early in the DO_ONCE_SLEEPABLE() macro.\nlib/once.c-81-\t\t */\n"
}

gemini-3.1-pro-preview

null

null

							input: 5618
							output: 28
							thoughts: 48
						

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**Investigating a Code Snippet**

Alright, let's see... this bit of code is popping up in `fs/resctrl/rdtgroup.c`. Ah, interesting, that's where the resource control stuff lives, so I'd expect it to be used there, controlling cache allocation and such. But then there's this `get_random_sleepable_once` function... Wait a second, isn't *that* used in a few more places than I initially thought? I need to check the call graph for `get_random_sleepable_once` because this suggests that this is more widely scoped and a broader dependency than I first suspected. I wonder if there are any subtle interactions to be aware of? It's time to dig deeper and see where else this function is being called and whether the shared context is important. This feels like it warrants a closer look at the bigger picture before I proceed.

{
  "Expression": "get_random_sleepable_once",
  "PathPrefix": ""
}

{
  "Output": "include/linux/net.h=338=do {\t\t\t\t\t\t\t\t\t\\\n--\ninclude/linux/net.h-354-\tget_random_once((buf), (nbytes))\ninclude/linux/net.h:355:#define net_get_random_sleepable_once(buf, nbytes)\t\t\\\ninclude/linux/net.h:356:\tget_random_sleepable_once((buf), (nbytes))\ninclude/linux/net.h-357-\n--\ninclude/linux/once.h=17=void __do_once_sleepable_done(bool *done, struct static_key_true *once_key,\n--\ninclude/linux/once.h-82-\ninclude/linux/once.h:83:#define get_random_sleepable_once(buf, nbytes)\t\t\t\t     \\\ninclude/linux/once.h-84-\tDO_ONCE_SLEEPABLE(get_random_bytes, (buf), (nbytes))\n--\nnet/ipv4/inet_hashtables.c=34=static void inet_init_ehash_secret(void)\nnet/ipv4/inet_hashtables.c-35-{\nnet/ipv4/inet_hashtables.c:36:\tnet_get_random_sleepable_once(\u0026inet_ehash_secret,\nnet/ipv4/inet_hashtables.c-37-\t\t\t\t      sizeof(inet_ehash_secret));\n--\nnet/ipv4/inet_hashtables.c=1040=int __inet_hash_connect(struct inet_timewait_death_row *death_row,\n--\nnet/ipv4/inet_hashtables.c-1080-\nnet/ipv4/inet_hashtables.c:1081:\tget_random_sleepable_once(table_perturb,\nnet/ipv4/inet_hashtables.c-1082-\t\t\t\t  INET_TABLE_PERTURB_SIZE * sizeof(*table_perturb));\n--\nnet/ipv6/inet6_hashtables.c=26=void inet6_init_ehash_secret(void)\nnet/ipv6/inet6_hashtables.c-27-{\nnet/ipv6/inet6_hashtables.c:28:\tnet_get_random_sleepable_once(\u0026inet6_ehash_secret,\nnet/ipv6/inet6_hashtables.c-29-\t\t\t\t      sizeof(inet6_ehash_secret));\nnet/ipv6/inet6_hashtables.c:30:\tnet_get_random_sleepable_once(\u0026tcp_ipv6_hash_secret,\nnet/ipv6/inet6_hashtables.c-31-\t\t\t\t      sizeof(tcp_ipv6_hash_secret));\n"
}

gemini-3.1-pro-preview

null

null

							input: 6584
							output: 156
							thoughts: 79
						

**Fuzzing Target Identification**

Alright, looking at this code, it's pretty clear that `__inet_hash_connect` is a key function involved in network connection setup. That alone makes it a prime candidate for fuzzing – it's definitely reachable within a critical part of the system. The fact that the change defers `static_branch_disable` to a workqueue suggests a potential for interesting concurrency-related issues. I'm going to flag this as `WorthFuzzing=true`. To zero in on the interesting pieces of this section, I'll pay specific attention to the `__do_once_sleepable_done` symbol as a focus point. No special configuration is needed to make this interesting, from what I can see.

{
  "EnableConfigs": [],
  "FocusSymbols": [
    "__do_once_sleepable_done"
  ],
  "Reasoning": "The patch modifies `__do_once_sleepable_done` in `lib/once.c` to defer the static branch disable operation to a workqueue using `once_disable_jump`. This is a functional change in a core kernel primitive used by `DO_ONCE_SLEEPABLE` and `get_random_sleepable_once`, which are reachable during network connection setup (e.g., `__inet_hash_connect`). It is worth fuzzing to ensure the deferred workqueue execution does not introduce regressions or race conditions.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": null,
  "FocusSymbols": [
    "__do_once_sleepable_done"
  ],
  "Reasoning": "The patch modifies `__do_once_sleepable_done` in `lib/once.c` to defer the static branch disable operation to a workqueue using `once_disable_jump`. This is a functional change in a core kernel primitive used by `DO_ONCE_SLEEPABLE` and `get_random_sleepable_once`, which are reachable during network connection setup (e.g., `__inet_hash_connect`). It is worth fuzzing to ensure the deferred workqueue execution does not introduce regressions or race conditions.",
  "WorthFuzzing": true
}

{
  "WorthFuzzing": true
}

null

best-expensive

null

{
  "KMSANReasoning": "The patch modifies the `__do_once_sleepable_done` function in `lib/once.c` to use `once_disable_jump` instead of `static_branch_disable`. This is related to the internal implementation of the `DO_ONCE` macro and static keys, likely to handle module unloading or deferred static branch disabling correctly. This change does not introduce any new data structures, memory allocations, or user-space copies. There is no risk of uninitialized memory usage or info-leaks. Any potential bugs introduced would be related to static keys, locking, or module state, which are covered by standard kernel debugging tools and KASAN/LOCKDEP, not KMSAN.",
  "NeedsKMSAN": false
}

You are an expert Linux kernel security engineer specializing in kernel memory
error detectors (KASAN and KMSAN). Your job is to review the provided patch series and
determine if the code changes justify spawning a dedicated KMSAN (KernelMemorySanitizer)
fuzzing session in addition to standard KASAN fuzzing.

CRITICAL DISTINCTION BETWEEN KASAN AND KMSAN:
- Standard KASAN kernel builds (upstream-apparmor-kasan.config) already enable
  a comprehensive suite of debugging tools and sanitizers, including KASAN
  (out-of-bounds accesses, use-after-free, double free, invalid free), LOCKDEP
  (locking bugs and deadlocks), UB-sanitizers, and memory corruption checks.
- KMSAN (KernelMemorySanitizer) detects reads of UNINITIALIZED memory (stack, heap,
  or page allocations) and kernel-to-user memory info-leaks.

Rule: THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN,
LOCKDEP, OR OTHER STANDARD BUG DETECTORS.
A dedicated KMSAN fuzzing session incurs significant resource costs. You must ONLY
set NeedsKMSAN=true if the code changes introduce or expose UNINITIALIZED MEMORY risks
that are detected ONLY by KMSAN.

Look holistically at the patch series and surrounding code. Even if no direct
uninitialized field accesses or new buffer allocations are added in the diff itself,
a patch may alter control flow, bounds checking, or data length calculations in ways
that change how the rest of the code operates on existing buffers (e.g. allowing
uninitialized stack/heap memory to be read, copied to user space, or used in control
flow). Do not hesitate to use your code access tools to inspect the surrounding code,
called functions, and callers.

Set NeedsKMSAN=true ONLY IF the patch introduces or modifies:
1. Kernel structures sent to user space (via copy_to_user, put_user, netlink skb
   attributes, ioctl output arguments, socket options, or BPF buffers) where fields
   or structure padding might not be fully initialized/zeroed.
2. Conditional logic or branching that depends on potentially uninitialized variables
   or struct fields.
3. Allocation or initialization of complex data structures where uninitialized fields
   could be read later in reachable code paths.
4. Bounds checks, lengths, or logic in a way that allows surrounding code to access
   uninitialized bytes of existing buffers.

Set NeedsKMSAN=false IF:
- The code changes primarily risk out-of-bounds access, array overflows, NULL pointer
  dereferences, locking deadlocks, or use-after-free bugs (these are already caught
  by KASAN, LOCKDEP, or standard bug detectors).
- All stack/heap structures touched or introduced by the patch are fully zeroed
  or initialized (e.g. using = {0}, memset, kzalloc) before being read or copied.
- The patch does not introduce any risk of uninitialized memory usage or info-leaks.

Use your code access tools to inspect the surrounding code if necessary, then provide
detailed KMSANReasoning contrasting KASAN vs KMSAN applicability for this patch.
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 c57654f24eaa6a6811bd8a3d9cceef2d7e2b2b7c
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Aug 25 14:47:11 2026 +0000

    syz-cluster: applied patch under review

diff --git a/lib/once.c b/lib/once.c
index d801bfa945e63..0a0a919156e05 100644
--- a/lib/once.c
+++ b/lib/once.c
@@ -93,6 +93,6 @@ void __do_once_sleepable_done(bool *done, struct static_key_true *once_key,
 {
 	*done = true;
 	mutex_unlock(&once_mutex);
-	static_branch_disable(once_key);
+	once_disable_jump(once_key, mod);
 }
 EXPORT_SYMBOL(__do_once_sleepable_done);

gemini-3.1-pro-preview

null

null

							input: 1951
							output: 19
							thoughts: 128
						

**Analyzing a `lib/once.c` Patch**

Okay, so this patch is touching `__do_once_sleepable_done` in `lib/once.c`. It looks like it's swapping out a `static_branch_disable(once_key);` call for `once_disable_jump(once_key, mod);`. I need to understand why. First things first, I should quickly verify both `lib/once.c` and specifically `once_disable_jump` if necessary, to get the full context.

My initial thought is to make sure this doesn't accidentally introduce any uninitialized memory risks, but that wouldn't make sense since we are dealing with static branches and `DO_ONCE` macros. This seems to be primarily concerned with jump labels and static keys.

Just to be absolutely certain, I'm going to double-check `once_disable_jump` to confirm that it's operating as expected and that the substitution is safe and semantically equivalent in this context. It's always good to be thorough with these types of changes in the kernel.

{
  "Expression": "once_disable_jump"
}

{
  "Output": "lib/once.c=14=static void once_deferred(struct work_struct *w)\n--\nlib/once.c-24-\nlib/once.c:25:static void once_disable_jump(struct static_key_true *key, struct module *mod)\nlib/once.c-26-{\n--\nlib/once.c=60=void __do_once_done(bool *done, struct static_key_true *once_key,\n--\nlib/once.c-65-\tspin_unlock_irqrestore(\u0026once_lock, *flags);\nlib/once.c:66:\tonce_disable_jump(once_key, mod);\nlib/once.c-67-}\n--\nlib/once.c=90=void __do_once_sleepable_done(bool *done, struct static_key_true *once_key,\n--\nlib/once.c-95-\tmutex_unlock(\u0026once_mutex);\nlib/once.c:96:\tonce_disable_jump(once_key, mod);\nlib/once.c-97-}\n"
}

gemini-3.1-pro-preview

null

null

							input: 2610
							output: 171
							thoughts: 115
						

**My Assessment of the Patch**

Okay, so this patch is switching `static_branch_disable(once_key)` to `once_disable_jump(once_key, mod)`. This is clearly aimed at addressing a problem specifically within modules, likely around how `DO_ONCE` is handled. The current method with `static_branch_disable` seems to be problematic or require some delayed action, which is what `once_disable_jump` is designed to provide.

Crucially, from what I can tell, this has *zero* bearing on the issues KMSAN is designed to detect. There's no hint of uninitialized memory vulnerabilities, potential information leaks, or anything else that KMSAN would flag. This is purely a control flow and static key correction.

Therefore, I'm confident in setting `NeedsKMSAN=false`. It's simply not relevant.

{
  "KMSANReasoning": "The patch modifies the `__do_once_sleepable_done` function in `lib/once.c` to use `once_disable_jump` instead of `static_branch_disable`. This is related to the internal implementation of the `DO_ONCE` macro and static keys, likely to handle module unloading or deferred static branch disabling correctly. This change does not introduce any new data structures, memory allocations, or user-space copies. There is no risk of uninitialized memory usage or info-leaks. Any potential bugs introduced would be related to static keys, locking, or module state, which are covered by standard kernel debugging tools and KASAN/LOCKDEP, not KMSAN.",
  "NeedsKMSAN": false
}

{
  "KMSANReasoning": "The patch modifies the `__do_once_sleepable_done` function in `lib/once.c` to use `once_disable_jump` instead of `static_branch_disable`. This is related to the internal implementation of the `DO_ONCE` macro and static keys, likely to handle module unloading or deferred static branch disabling correctly. This change does not introduce any new data structures, memory allocations, or user-space copies. There is no risk of uninitialized memory usage or info-leaks. Any potential bugs introduced would be related to static keys, locking, or module state, which are covered by standard kernel debugging tools and KASAN/LOCKDEP, not KMSAN.",
  "NeedsKMSAN": false
}