| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/07/16 13:10 | flow | patch-triage |
3mArgs:null Results: {
"EnableConfigs": [
"BPF_JIT",
"BPF_SYSCALL",
"EXECMEM"
],
"FocusSymbols": [
"alloc_new_pack",
"bpf_prog_pack_alloc",
"arch_bpf_trampoline_size",
"bpf_dispatcher_change_prog"
],
"Reasoning": "The patch modifies BPF JIT memory allocation logic, introducing `bpf_jit_alloc_exec_rw` and updating `bpf_jit_alloc_exec` to use `execmem_alloc`. It also changes x86 BPF JIT memory initialization and updates BPF trampoline and dispatcher logic to use the new allocation methods. These are functional changes to reachable core BPF logic.",
"WorthFuzzing": true
} |
| 1/1 | 2026/07/16 13:10 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit 9da7140d12f1f67b481b05d040c3d94ed57abd7d\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Thu Jul 16 13:10:27 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c\nindex fb67217fddcd37..079f8c7e9e3cde 100644\n--- a/arch/x86/mm/init.c\n+++ b/arch/x86/mm/init.c\n@@ -1107,10 +1107,10 @@ struct execmem_info __init *execmem_arch_setup(void)\n \t\t\t\t.alignment = MODULE_ALIGN,\n \t\t\t},\n \t\t\t[EXECMEM_BPF] = {\n-\t\t\t\t.flags\t= EXECMEM_KASAN_SHADOW,\n+\t\t\t\t.flags\t= flags,\n \t\t\t\t.start\t= start,\n \t\t\t\t.end\t= MODULES_END,\n-\t\t\t\t.pgprot\t= PAGE_KERNEL,\n+\t\t\t\t.pgprot\t= pgprot,\n \t\t\t\t.alignment = MODULE_ALIGN,\n \t\t\t},\n \t\t\t[EXECMEM_MODULE_DATA] = {\ndiff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c\nindex de7515ea1beae8..b2feec81e2312e 100644\n--- a/arch/x86/net/bpf_jit_comp.c\n+++ b/arch/x86/net/bpf_jit_comp.c\n@@ -3703,13 +3703,12 @@ int arch_bpf_trampoline_size(const struct btf_func_model *m, u32 flags,\n \tint ret;\n \n \t/* Allocate a temporary buffer for __arch_prepare_bpf_trampoline().\n-\t * This will NOT cause fragmentation in direct map, as we do not\n-\t * call set_memory_*() on this buffer.\n \t *\n \t * We cannot use kvmalloc here, because we need image to be in\n \t * module memory range.\n+\t * Since it must be writable use bpf_jit_alloc_exec_rw().\n \t */\n-\timage = bpf_jit_alloc_exec(PAGE_SIZE);\n+\timage = bpf_jit_alloc_exec_rw(PAGE_SIZE);\n \tif (!image)\n \t\treturn -ENOMEM;\n \ndiff --git a/include/linux/filter.h b/include/linux/filter.h\nindex 14acb2455746fc..32d5297c557e5b 100644\n--- a/include/linux/filter.h\n+++ b/include/linux/filter.h\n@@ -1333,6 +1333,7 @@ bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,\n void bpf_jit_binary_free(struct bpf_binary_header *hdr);\n u64 bpf_jit_alloc_exec_limit(void);\n void *bpf_jit_alloc_exec(unsigned long size);\n+void *bpf_jit_alloc_exec_rw(unsigned long size);\n void bpf_jit_free_exec(void *addr);\n void bpf_jit_free(struct bpf_prog *fp);\n struct bpf_binary_header *\ndiff --git a/kernel/bpf/core.c b/kernel/bpf/core.c\nindex 47fe047ad30b88..e2076667b24517 100644\n--- a/kernel/bpf/core.c\n+++ b/kernel/bpf/core.c\n@@ -916,6 +916,11 @@ static LIST_HEAD(pack_list);\n \n #define BPF_PROG_CHUNK_COUNT (BPF_PROG_PACK_SIZE / BPF_PROG_CHUNK_SIZE)\n \n+static bool bpf_jit_mem_is_rox(void)\n+{\n+\treturn execmem_is_rox(EXECMEM_BPF);\n+}\n+\n static struct bpf_prog_pack *alloc_new_pack(bpf_jit_fill_hole_t bpf_fill_ill_insns)\n {\n \tstruct bpf_prog_pack *pack;\n@@ -927,16 +932,18 @@ static struct bpf_prog_pack *alloc_new_pack(bpf_jit_fill_hole_t bpf_fill_ill_ins\n \tpack-\u003eptr = bpf_jit_alloc_exec(BPF_PROG_PACK_SIZE);\n \tif (!pack-\u003eptr)\n \t\tgoto out;\n-\tbpf_fill_ill_insns(pack-\u003eptr, BPF_PROG_PACK_SIZE);\n \tbitmap_zero(pack-\u003ebitmap, BPF_PROG_PACK_SIZE / BPF_PROG_CHUNK_SIZE);\n \n \tif (static_branch_unlikely(\u0026bpf_pred_flush_enabled))\n \t\tpack-\u003earch_flush_needed = true;\n-\tset_vm_flush_reset_perms(pack-\u003eptr);\n-\terr = set_memory_rox((unsigned long)pack-\u003eptr,\n-\t\t\t BPF_PROG_PACK_SIZE / PAGE_SIZE);\n-\tif (err)\n-\t\tgoto out;\n+\tif (!bpf_jit_mem_is_rox()) {\n+\t\tbpf_fill_ill_insns(pack-\u003eptr, BPF_PROG_PACK_SIZE);\n+\t\tset_vm_flush_reset_perms(pack-\u003eptr);\n+\t\terr = set_memory_rox((unsigned long)pack-\u003eptr,\n+\t\t\t\t BPF_PROG_PACK_SIZE / PAGE_SIZE);\n+\t\tif (err)\n+\t\t\tgoto out;\n+\t}\n \tlist_add_tail(\u0026pack-\u003elist, \u0026pack_list);\n \treturn pack;\n \n@@ -965,7 +972,7 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns, bool\n \t\t\tpr_warn_once(\"BPF: Predictors not flushed for allocations greater than BPF_PROG_PACK_SIZE\\n\");\n \t\tsize = round_up(size, PAGE_SIZE);\n \t\tptr = bpf_jit_alloc_exec(size);\n-\t\tif (ptr) {\n+\t\tif (ptr \u0026\u0026 !bpf_jit_mem_is_rox()) {\n \t\t\tint err;\n \n \t\t\tbpf_fill_ill_insns(ptr, size);\n@@ -1116,12 +1123,17 @@ void bpf_jit_uncharge_modmem(u32 size)\n \tatomic_long_sub(size, \u0026bpf_jit_current);\n }\n \n-void *__weak bpf_jit_alloc_exec(unsigned long size)\n+void *bpf_jit_alloc_exec(unsigned long size)\n {\n \treturn execmem_alloc(EXECMEM_BPF, size);\n }\n \n-void __weak bpf_jit_free_exec(void *addr)\n+void *bpf_jit_alloc_exec_rw(unsigned long size)\n+{\n+\treturn execmem_alloc_rw(EXECMEM_BPF, size);\n+}\n+\n+void bpf_jit_free_exec(void *addr)\n {\n \texecmem_free(addr);\n }\ndiff --git a/kernel/bpf/dispatcher.c b/kernel/bpf/dispatcher.c\nindex ea2d60dc1feeb7..79f0c222c58340 100644\n--- a/kernel/bpf/dispatcher.c\n+++ b/kernel/bpf/dispatcher.c\n@@ -148,7 +148,10 @@ void bpf_dispatcher_change_prog(struct bpf_dispatcher *d, struct bpf_prog *from,\n \t\td-\u003eimage = bpf_prog_pack_alloc(PAGE_SIZE, bpf_jit_fill_hole_with_zero, false);\n \t\tif (!d-\u003eimage)\n \t\t\tgoto out;\n-\t\td-\u003erw_image = bpf_jit_alloc_exec(PAGE_SIZE);\n+\t\t/* d-\u003erw_image doesn't need to be in module memory range, so we\n+\t\t * can use vzalloc.\n+\t\t */\n+\t\td-\u003erw_image = vzalloc(PAGE_SIZE);\n \t\tif (!d-\u003erw_image) {\n \t\t\tbpf_prog_pack_free(d-\u003eimage, PAGE_SIZE);\n \t\t\td-\u003eimage = NULL;\n"
} |
| 2/1 | 2026/07/16 13:10 | agent | patch-evaluator |
2mModel:gemini-3.1-pro-preview Args: null Results: {
"EnableConfigs": [
"BPF_JIT",
"BPF_SYSCALL",
"EXECMEM"
],
"FocusSymbols": [
"alloc_new_pack",
"bpf_prog_pack_alloc",
"arch_bpf_trampoline_size",
"bpf_dispatcher_change_prog"
],
"Reasoning": "The patch modifies BPF JIT memory allocation logic, introducing `bpf_jit_alloc_exec_rw` and updating `bpf_jit_alloc_exec` to use `execmem_alloc`. It also changes x86 BPF JIT memory initialization and updates BPF trampoline and dispatcher logic to use the new allocation methods. These are functional changes to reachable core BPF logic.",
"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 9da7140d12f1f67b481b05d040c3d94ed57abd7d
Author: syz-cluster <triage@syzkaller.com>
Date: Thu Jul 16 13:10:27 2026 +0000
syz-cluster: applied patch under review
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index fb67217fddcd37..079f8c7e9e3cde 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -1107,10 +1107,10 @@ struct execmem_info __init *execmem_arch_setup(void)
.alignment = MODULE_ALIGN,
},
[EXECMEM_BPF] = {
- .flags = EXECMEM_KASAN_SHADOW,
+ .flags = flags,
.start = start,
.end = MODULES_END,
- .pgprot = PAGE_KERNEL,
+ .pgprot = pgprot,
.alignment = MODULE_ALIGN,
},
[EXECMEM_MODULE_DATA] = {
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index de7515ea1beae8..b2feec81e2312e 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -3703,13 +3703,12 @@ int arch_bpf_trampoline_size(const struct btf_func_model *m, u32 flags,
int ret;
/* Allocate a temporary buffer for __arch_prepare_bpf_trampoline().
- * This will NOT cause fragmentation in direct map, as we do not
- * call set_memory_*() on this buffer.
*
* We cannot use kvmalloc here, because we need image to be in
* module memory range.
+ * Since it must be writable use bpf_jit_alloc_exec_rw().
*/
- image = bpf_jit_alloc_exec(PAGE_SIZE);
+ image = bpf_jit_alloc_exec_rw(PAGE_SIZE);
if (!image)
return -ENOMEM;
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 14acb2455746fc..32d5297c557e5b 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -1333,6 +1333,7 @@ bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,
void bpf_jit_binary_free(struct bpf_binary_header *hdr);
u64 bpf_jit_alloc_exec_limit(void);
void *bpf_jit_alloc_exec(unsigned long size);
+void *bpf_jit_alloc_exec_rw(unsigned long size);
void bpf_jit_free_exec(void *addr);
void bpf_jit_free(struct bpf_prog *fp);
struct bpf_binary_header *
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 47fe047ad30b88..e2076667b24517 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -916,6 +916,11 @@ static LIST_HEAD(pack_list);
#define BPF_PROG_CHUNK_COUNT (BPF_PROG_PACK_SIZE / BPF_PROG_CHUNK_SIZE)
+static bool bpf_jit_mem_is_rox(void)
+{
+ return execmem_is_rox(EXECMEM_BPF);
+}
+
static struct bpf_prog_pack *alloc_new_pack(bpf_jit_fill_hole_t bpf_fill_ill_insns)
{
struct bpf_prog_pack *pack;
@@ -927,16 +932,18 @@ static struct bpf_prog_pack *alloc_new_pack(bpf_jit_fill_hole_t bpf_fill_ill_ins
pack->ptr = bpf_jit_alloc_exec(BPF_PROG_PACK_SIZE);
if (!pack->ptr)
goto out;
- bpf_fill_ill_insns(pack->ptr, BPF_PROG_PACK_SIZE);
bitmap_zero(pack->bitmap, BPF_PROG_PACK_SIZE / BPF_PROG_CHUNK_SIZE);
if (static_branch_unlikely(&bpf_pred_flush_enabled))
pack->arch_flush_needed = true;
- set_vm_flush_reset_perms(pack->ptr);
- err = set_memory_rox((unsigned long)pack->ptr,
- BPF_PROG_PACK_SIZE / PAGE_SIZE);
- if (err)
- goto out;
+ if (!bpf_jit_mem_is_rox()) {
+ bpf_fill_ill_insns(pack->ptr, BPF_PROG_PACK_SIZE);
+ set_vm_flush_reset_perms(pack->ptr);
+ err = set_memory_rox((unsigned long)pack->ptr,
+ BPF_PROG_PACK_SIZE / PAGE_SIZE);
+ if (err)
+ goto out;
+ }
list_add_tail(&pack->list, &pack_list);
return pack;
@@ -965,7 +972,7 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns, bool
pr_warn_once("BPF: Predictors not flushed for allocations greater than BPF_PROG_PACK_SIZE\n");
size = round_up(size, PAGE_SIZE);
ptr = bpf_jit_alloc_exec(size);
- if (ptr) {
+ if (ptr && !bpf_jit_mem_is_rox()) {
int err;
bpf_fill_ill_insns(ptr, size);
@@ -1116,12 +1123,17 @@ void bpf_jit_uncharge_modmem(u32 size)
atomic_long_sub(size, &bpf_jit_current);
}
-void *__weak bpf_jit_alloc_exec(unsigned long size)
+void *bpf_jit_alloc_exec(unsigned long size)
{
return execmem_alloc(EXECMEM_BPF, size);
}
-void __weak bpf_jit_free_exec(void *addr)
+void *bpf_jit_alloc_exec_rw(unsigned long size)
+{
+ return execmem_alloc_rw(EXECMEM_BPF, size);
+}
+
+void bpf_jit_free_exec(void *addr)
{
execmem_free(addr);
}
diff --git a/kernel/bpf/dispatcher.c b/kernel/bpf/dispatcher.c
index ea2d60dc1feeb7..79f0c222c58340 100644
--- a/kernel/bpf/dispatcher.c
+++ b/kernel/bpf/dispatcher.c
@@ -148,7 +148,10 @@ void bpf_dispatcher_change_prog(struct bpf_dispatcher *d, struct bpf_prog *from,
d->image = bpf_prog_pack_alloc(PAGE_SIZE, bpf_jit_fill_hole_with_zero, false);
if (!d->image)
goto out;
- d->rw_image = bpf_jit_alloc_exec(PAGE_SIZE);
+ /* d->rw_image doesn't need to be in module memory range, so we
+ * can use vzalloc.
+ */
+ d->rw_image = vzalloc(PAGE_SIZE);
if (!d->rw_image) {
bpf_prog_pack_free(d->image, PAGE_SIZE);
d->image = NULL;
|
| 3/2 | 2026/07/16 13:10 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 3733 output: 40 thoughts: 273 Thoughts: **Analyzing a BPF JIT Memory Allocation Patch** Okay, so I'm looking at this patch and my initial thought is, "Ah, it's messing with BPF JIT memory allocation." Specifically, I see it's touching `bpf_jit_alloc_exec`, introducing `bpf_jit_alloc_exec_rw`, and then there are changes to `arch/x86/mm/init.c`. Interesting. The `init.c` changes look like they're making things more flexible by using `flags` and `pgprot` instead of those hardcoded constants (`EXECMEM_KASAN_SHADOW`, `PAGE_KERNEL`) for `EXECMEM_BPF`. A good design decision. Then there's the `bpf_dispatcher_change_prog` change. It’s using `vzalloc` for `d->rw_image` now, instead of the potentially more specific allocation of `bpf_jit_alloc_exec`. And there's also a new function, `bpf_jit_mem_is_rox()`, appearing in `kernel/bpf/core.c`. Hmm, a new primitive? Alright, this is fundamental. This patch clearly modifies the core BPF JIT memory allocation and x86 BPF JIT specifically. Given BPF's widespread usage, this definitely is reachable. It sees a lot of use. Is it fuzzable? Absolutely. It’s functional, so it should be. Okay, let's take a closer look at `arch/x86/mm/init.c` and see exactly what those `flags` and `pgprot` are. I'll get the details on the use of `read-file` around line 1107... and see if there are any subtle implications. |
| 4/2 | 2026/07/16 13:10 | tool | read-file |
0mArgs:{
"File": "arch/x86/mm/init.c",
"FirstLine": 1090,
"LineCount": 50
}Results: {
"Contents": "1090:\t\t\t\t\t.start\t= start,\n1091:\t\t\t\t\t.end\t= MODULES_END,\n1092:\t\t\t\t\t.pgprot\t= pgprot,\n1093:\t\t\t\t\t.alignment = MODULE_ALIGN,\n1094:\t\t\t\t},\n1095:\t\t\t\t[EXECMEM_KPROBES] = {\n1096:\t\t\t\t\t.flags\t= flags,\n1097:\t\t\t\t\t.start\t= start,\n1098:\t\t\t\t\t.end\t= MODULES_END,\n1099:\t\t\t\t\t.pgprot\t= PAGE_KERNEL_ROX,\n1100:\t\t\t\t\t.alignment = MODULE_ALIGN,\n1101:\t\t\t\t},\n1102:\t\t\t\t[EXECMEM_FTRACE] = {\n1103:\t\t\t\t\t.flags\t= flags,\n1104:\t\t\t\t\t.start\t= start,\n1105:\t\t\t\t\t.end\t= MODULES_END,\n1106:\t\t\t\t\t.pgprot\t= pgprot,\n1107:\t\t\t\t\t.alignment = MODULE_ALIGN,\n1108:\t\t\t\t},\n1109:\t\t\t\t[EXECMEM_BPF] = {\n1110:\t\t\t\t\t.flags\t= flags,\n1111:\t\t\t\t\t.start\t= start,\n1112:\t\t\t\t\t.end\t= MODULES_END,\n1113:\t\t\t\t\t.pgprot\t= pgprot,\n1114:\t\t\t\t\t.alignment = MODULE_ALIGN,\n1115:\t\t\t\t},\n1116:\t\t\t\t[EXECMEM_MODULE_DATA] = {\n1117:\t\t\t\t\t.flags\t= EXECMEM_KASAN_SHADOW,\n1118:\t\t\t\t\t.start\t= start,\n1119:\t\t\t\t\t.end\t= MODULES_END,\n1120:\t\t\t\t\t.pgprot\t= PAGE_KERNEL,\n1121:\t\t\t\t\t.alignment = MODULE_ALIGN,\n1122:\t\t\t\t},\n1123:\t\t\t},\n1124:\t\t};\n1125:\t\n1126:\t\treturn \u0026execmem_info;\n1127:\t}\n1128:\t#endif /* CONFIG_EXECMEM */\n"
} |
| 5/2 | 2026/07/16 13:10 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 4968 output: 36 thoughts: 85 Thoughts: **Analyzing the Recent Code Changes** Okay, so I'm looking into these memory allocation updates. The core architectural setup adjustments seem to be nestled within `arch/x86/mm/init.c`, specifically the `execmem_arch_setup` function. That's the first key area to understand. Then, it looks like the actual BPF JIT memory allocation happens in `kernel/bpf/core.c` – specifically the `bpf_jit_alloc_exec` and `bpf_jit_alloc_exec_rw` routines. Right, that makes sense; these functions are responsible for the just-in-time compilation and related memory. I need to take a closer look at `kernel/bpf/core.c`, probably starting around line 916. That's likely where the allocation strategy itself is implemented, so let's see what's going on there. |
| 6/2 | 2026/07/16 13:10 | tool | read-file |
0mArgs:{
"File": "kernel/bpf/core.c",
"FirstLine": 910,
"LineCount": 50
}Results: {
"Contents": " 910:\t * greater than or equal to 2MB.\n 911:\t */\n 912:\t#define BPF_PROG_PACK_SIZE (SZ_2M * num_possible_nodes())\n 913:\t#else\n 914:\t#define BPF_PROG_PACK_SIZE PAGE_SIZE\n 915:\t#endif\n 916:\t\n 917:\t#define BPF_PROG_CHUNK_COUNT (BPF_PROG_PACK_SIZE / BPF_PROG_CHUNK_SIZE)\n 918:\t\n 919:\tstatic bool bpf_jit_mem_is_rox(void)\n 920:\t{\n 921:\t\treturn execmem_is_rox(EXECMEM_BPF);\n 922:\t}\n 923:\t\n 924:\tstatic struct bpf_prog_pack *alloc_new_pack(bpf_jit_fill_hole_t bpf_fill_ill_insns)\n 925:\t{\n 926:\t\tstruct bpf_prog_pack *pack;\n 927:\t\tint err;\n 928:\t\n 929:\t\tpack = kzalloc_flex(*pack, bitmap, BITS_TO_LONGS(BPF_PROG_CHUNK_COUNT));\n 930:\t\tif (!pack)\n 931:\t\t\treturn NULL;\n 932:\t\tpack-\u003eptr = bpf_jit_alloc_exec(BPF_PROG_PACK_SIZE);\n 933:\t\tif (!pack-\u003eptr)\n 934:\t\t\tgoto out;\n 935:\t\tbitmap_zero(pack-\u003ebitmap, BPF_PROG_PACK_SIZE / BPF_PROG_CHUNK_SIZE);\n 936:\t\n 937:\t\tif (static_branch_unlikely(\u0026bpf_pred_flush_enabled))\n 938:\t\t\tpack-\u003earch_flush_needed = true;\n 939:\t\tif (!bpf_jit_mem_is_rox()) {\n 940:\t\t\tbpf_fill_ill_insns(pack-\u003eptr, BPF_PROG_PACK_SIZE);\n 941:\t\t\tset_vm_flush_reset_perms(pack-\u003eptr);\n 942:\t\t\terr = set_memory_rox((unsigned long)pack-\u003eptr,\n 943:\t\t\t\t\t BPF_PROG_PACK_SIZE / PAGE_SIZE);\n 944:\t\t\tif (err)\n 945:\t\t\t\tgoto out;\n 946:\t\t}\n 947:\t\tlist_add_tail(\u0026pack-\u003elist, \u0026pack_list);\n 948:\t\treturn pack;\n 949:\t\n 950:\tout:\n 951:\t\tbpf_jit_free_exec(pack-\u003eptr);\n 952:\t\tkfree(pack);\n 953:\t\treturn NULL;\n 954:\t}\n 955:\t\n 956:\tvoid *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns, bool was_classic)\n 957:\t{\n 958:\t\tunsigned int nbits = BPF_PROG_SIZE_TO_NBITS(size);\n 959:\t\tstruct bpf_prog_pack *pack, *fallback_pack = NULL;\n"
} |
| 7/2 | 2026/07/16 13:10 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 6144 output: 45 thoughts: 112 Thoughts: **Analyzing BPF JIT Compilation for Optimization** Okay, so I need to zero in on a specific area within the BPF JIT compilation process. The core functions I should prioritize for this analysis are: `alloc_new_pack`, `bpf_prog_pack_alloc`, `arch_bpf_trampoline_size`, and `bpf_dispatcher_change_prog`. My immediate thought is that `arch_bpf_trampoline_size` feels like a critical point. Hmm, it seems this function interacts with `bpf_jit_alloc_exec_rw`. Right, that's where the memory allocation and potential code generation would happen. I need to refresh my memory on how this all fits together. Best to jump into the code and examine `arch/x86/net/bpf_jit_comp.c` around line 3703. That's the likely location for some key changes. Gotta understand how the trampoline size calculation relates to the RW allocation within the JIT environment. |
| 8/2 | 2026/07/16 13:10 | tool | read-file |
0mArgs:{
"File": "arch/x86/net/bpf_jit_comp.c",
"FirstLine": 3690,
"LineCount": 50
}Results: {
"Contents": "3690:\t\ttmp = bpf_arch_text_copy(image, rw_image, size);\n3691:\t\tif (IS_ERR(tmp))\n3692:\t\t\tret = PTR_ERR(tmp);\n3693:\tout:\n3694:\t\tkvfree(rw_image);\n3695:\t\treturn ret;\n3696:\t}\n3697:\t\n3698:\tint arch_bpf_trampoline_size(const struct btf_func_model *m, u32 flags,\n3699:\t\t\t\t struct bpf_tramp_nodes *tnodes, void *func_addr)\n3700:\t{\n3701:\t\tstruct bpf_tramp_image im;\n3702:\t\tvoid *image;\n3703:\t\tint ret;\n3704:\t\n3705:\t\t/* Allocate a temporary buffer for __arch_prepare_bpf_trampoline().\n3706:\t\t *\n3707:\t\t * We cannot use kvmalloc here, because we need image to be in\n3708:\t\t * module memory range.\n3709:\t\t * Since it must be writable use bpf_jit_alloc_exec_rw().\n3710:\t\t */\n3711:\t\timage = bpf_jit_alloc_exec_rw(PAGE_SIZE);\n3712:\t\tif (!image)\n3713:\t\t\treturn -ENOMEM;\n3714:\t\n3715:\t\tret = __arch_prepare_bpf_trampoline(\u0026im, image, image + PAGE_SIZE, image,\n3716:\t\t\t\t\t\t m, flags, tnodes, func_addr);\n3717:\t\tbpf_jit_free_exec(image);\n3718:\t\treturn ret;\n3719:\t}\n3720:\t\n3721:\tstatic int emit_bpf_dispatcher(u8 **pprog, int a, int b, s64 *progs, u8 *image, u8 *buf)\n3722:\t{\n3723:\t\tu8 *jg_reloc, *prog = *pprog;\n3724:\t\tint pivot, err, jg_bytes = 1;\n3725:\t\ts64 jg_offset;\n3726:\t\n3727:\t\tif (a == b) {\n3728:\t\t\t/* Leaf node of recursion, i.e. not a range of indices\n3729:\t\t\t * anymore.\n3730:\t\t\t */\n3731:\t\t\tEMIT1(add_1mod(0x48, BPF_REG_3));\t/* cmp rdx,func */\n3732:\t\t\tif (!is_simm32(progs[a]))\n3733:\t\t\t\treturn -1;\n3734:\t\t\tEMIT2_off32(0x81, add_1reg(0xF8, BPF_REG_3),\n3735:\t\t\t\t progs[a]);\n3736:\t\t\terr = emit_cond_near_jump(\u0026prog,\t/* je func */\n3737:\t\t\t\t\t\t (void *)progs[a], image + (prog - buf),\n3738:\t\t\t\t\t\t X86_JE);\n3739:\t\t\tif (err)\n"
} |
| 9/2 | 2026/07/16 13:10 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 7356 output: 36 thoughts: 80 Thoughts: Here's my summary, as though I'm thinking through this process: **BPF JIT Compilation Configuration Verification** Okay, so I'm digging into this BPF JIT compilation issue. First things first, let's verify the necessary kernel configuration flags are enabled. I need to make sure `CONFIG_BPF_JIT` is set, obviously. Then, because the architecture-specific code is hanging out in `arch/x86/net/bpf_jit_comp.c`, I'll also confirm that `CONFIG_X86_64` is configured, since that seems relevant to that path. Finally, I'll need to confirm that `CONFIG_BPF_SYSCALL` is enabled, given that the underlying mechanism uses syscalls. With those prerequisites checked off, I'll go take a look at `kernel/bpf/dispatcher.c`. My hunch is that there's something potentially awry around line 148, so I'll start there and trace the logic. Let's see what's happening in that area. I need to understand how the dispatcher is interacting with the JIT. |
| 10/2 | 2026/07/16 13:10 | tool | read-file |
0mArgs:{
"File": "kernel/bpf/dispatcher.c",
"FirstLine": 140,
"LineCount": 50
}Results: {
"Contents": " 140:\t\tbool changed = false;\n 141:\t\tint prev_num_progs;\n 142:\t\n 143:\t\tif (from == to)\n 144:\t\t\treturn;\n 145:\t\n 146:\t\tmutex_lock(\u0026d-\u003emutex);\n 147:\t\tif (!d-\u003eimage) {\n 148:\t\t\td-\u003eimage = bpf_prog_pack_alloc(PAGE_SIZE, bpf_jit_fill_hole_with_zero, false);\n 149:\t\t\tif (!d-\u003eimage)\n 150:\t\t\t\tgoto out;\n 151:\t\t\t/* d-\u003erw_image doesn't need to be in module memory range, so we\n 152:\t\t\t * can use vzalloc.\n 153:\t\t\t */\n 154:\t\t\td-\u003erw_image = vzalloc(PAGE_SIZE);\n 155:\t\t\tif (!d-\u003erw_image) {\n 156:\t\t\t\tbpf_prog_pack_free(d-\u003eimage, PAGE_SIZE);\n 157:\t\t\t\td-\u003eimage = NULL;\n 158:\t\t\t\tgoto out;\n 159:\t\t\t}\n 160:\t\t\tbpf_image_ksym_init(d-\u003eimage, PAGE_SIZE, \u0026d-\u003eksym);\n 161:\t\t\tbpf_image_ksym_add(\u0026d-\u003eksym);\n 162:\t\t}\n 163:\t\n 164:\t\tprev_num_progs = d-\u003enum_progs;\n 165:\t\tchanged |= bpf_dispatcher_remove_prog(d, from);\n 166:\t\tchanged |= bpf_dispatcher_add_prog(d, to);\n 167:\t\n 168:\t\tif (!changed)\n 169:\t\t\tgoto out;\n 170:\t\n 171:\t\tbpf_dispatcher_update(d, prev_num_progs);\n 172:\tout:\n 173:\t\tmutex_unlock(\u0026d-\u003emutex);\n 174:\t}\n"
} |
| 11/2 | 2026/07/16 13:10 | llm | patch-evaluator |
1mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 8248 output: 32 thoughts: 48 Thoughts: **Examining the BPF JIT Configuration** Okay, so I see the configuration for `kernel/bpf/dispatcher.c` is driven by `CONFIG_BPF_JIT`. My next immediate thought is to verify whether the compilation of `dispatcher.c` is actually conditional based on this config. The most obvious place to do that is in `kernel/bpf/Makefile`. I need to quickly cross-reference that `Makefile` to confirm the dependency and understand the build process. Gotta make sure the JIT compiler dependency is handled correctly. |
| 12/2 | 2026/07/16 13:12 | tool | read-file |
0mArgs:{
"File": "kernel/bpf/Makefile",
"FirstLine": 1,
"LineCount": 50
}Results: {
"Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0\n 2:\tobj-y := core.o\n 3:\tifneq ($(CONFIG_BPF_JIT_ALWAYS_ON),y)\n 4:\t# ___bpf_prog_run() needs GCSE disabled on x86; see 3193c0836f203 for details\n 5:\tcflags-nogcse-$(CONFIG_X86)$(CONFIG_CC_IS_GCC) := -fno-gcse\n 6:\tendif\n 7:\tCFLAGS_core.o += -Wno-override-init $(cflags-nogcse-yy)\n 8:\t\n 9:\tobj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o inode.o helpers.o tnum.o cnum.o log.o token.o liveness.o const_fold.o\n 10:\tobj-$(CONFIG_BPF_SYSCALL) += bpf_iter.o map_iter.o task_iter.o prog_iter.o link_iter.o\n 11:\tobj-$(CONFIG_BPF_SYSCALL) += hashtab.o arraymap.o percpu_freelist.o bpf_lru_list.o lpm_trie.o map_in_map.o bloom_filter.o\n 12:\tobj-$(CONFIG_BPF_SYSCALL) += local_storage.o queue_stack_maps.o ringbuf.o bpf_insn_array.o\n 13:\tobj-$(CONFIG_BPF_SYSCALL) += bpf_local_storage.o bpf_task_storage.o\n 14:\tobj-$(CONFIG_BPF_SYSCALL) += fixups.o cfg.o states.o backtrack.o check_btf.o\n 15:\tobj-${CONFIG_BPF_LSM}\t += bpf_inode_storage.o\n 16:\tobj-$(CONFIG_BPF_SYSCALL) += disasm.o mprog.o\n 17:\tobj-$(CONFIG_BPF_JIT) += trampoline.o\n 18:\tobj-$(CONFIG_BPF_SYSCALL) += btf.o memalloc.o rqspinlock.o stream.o\n 19:\tifeq ($(CONFIG_MMU)$(CONFIG_64BIT),yy)\n 20:\tobj-$(CONFIG_BPF_SYSCALL) += arena.o range_tree.o\n 21:\tendif\n 22:\tobj-$(CONFIG_BPF_JIT) += dispatcher.o\n 23:\tifeq ($(CONFIG_NET),y)\n 24:\tobj-$(CONFIG_BPF_SYSCALL) += devmap.o\n 25:\tobj-$(CONFIG_BPF_SYSCALL) += cpumap.o\n 26:\tobj-$(CONFIG_BPF_SYSCALL) += offload.o\n 27:\tobj-$(CONFIG_BPF_SYSCALL) += net_namespace.o\n 28:\tobj-$(CONFIG_BPF_SYSCALL) += tcx.o\n 29:\tendif\n 30:\tifeq ($(CONFIG_PERF_EVENTS),y)\n 31:\tobj-$(CONFIG_BPF_SYSCALL) += stackmap.o\n 32:\tendif\n 33:\tifeq ($(CONFIG_CGROUPS),y)\n 34:\tobj-$(CONFIG_BPF_SYSCALL) += cgroup_iter.o bpf_cgrp_storage.o\n 35:\tendif\n 36:\tobj-$(CONFIG_CGROUP_BPF) += cgroup.o\n 37:\tifeq ($(CONFIG_INET),y)\n 38:\tobj-$(CONFIG_BPF_SYSCALL) += reuseport_array.o\n 39:\tendif\n 40:\tifeq ($(CONFIG_SYSFS),y)\n 41:\tobj-$(CONFIG_DEBUG_INFO_BTF) += sysfs_btf.o\n 42:\tendif\n 43:\tifeq ($(CONFIG_BPF_JIT),y)\n 44:\tobj-$(CONFIG_BPF_SYSCALL) += bpf_struct_ops.o\n 45:\tobj-$(CONFIG_BPF_SYSCALL) += cpumask.o\n 46:\t# bpf_lsm_proto.o must precede bpf_lsm.o. The current pahole logic\n 47:\t# deduplicates function prototypes within\n 48:\t# btf_encoder__add_saved_func() by keeping the first instance seen. We\n 49:\t# need the function prototype(s) in bpf_lsm_proto.o to take precedence\n 50:\t# over those within bpf_lsm.o. Having bpf_lsm_proto.o precede\n"
} |
| 13/2 | 2026/07/16 13:12 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 9642 output: 40 thoughts: 98 Thoughts: **Kernel Configuration Dependencies for BPF JIT and Related Features** Okay, so I'm looking at this build configuration and it looks like I need to make sure `CONFIG_BPF_JIT` is enabled – that's a given. I knew that, of course, but it's good to confirm. Then I also need to make sure `CONFIG_BPF_SYSCALL` is enabled; that's a common prerequisite for many BPF functionalities, so that makes sense. Hmm, and it looks like the changes in `arch/x86/mm/init.c` depend on `CONFIG_EXECMEM`. I should probably double-check that `arch/x86/mm/init.c` file again just to be sure I'm not missing anything crucial. Gotta get this right. |
| 14/2 | 2026/07/16 13:12 | tool | read-file |
0mArgs:{
"File": "arch/x86/mm/init.c",
"FirstLine": 1120,
"LineCount": 20
}Results: {
"Contents": "1120:\t\t\t\t\t.pgprot\t= PAGE_KERNEL,\n1121:\t\t\t\t\t.alignment = MODULE_ALIGN,\n1122:\t\t\t\t},\n1123:\t\t\t},\n1124:\t\t};\n1125:\t\n1126:\t\treturn \u0026execmem_info;\n1127:\t}\n1128:\t#endif /* CONFIG_EXECMEM */\n"
} |
| 15/2 | 2026/07/16 13:12 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 10065 output: 37 thoughts: 37 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience: **Kernel Configuration and BPF JIT Allocation** Alright, yep, definitely need to confirm that `CONFIG_EXECMEM` is enabled. It's a fundamental requirement, and I'm pretty certain it's baked into my understanding of how the JIT works. Can't bypass that memory allocation policy. Now, let me quickly pivot to `kernel/bpf/core.c`. I need to double-check my understanding, specifically the implementation details around `bpf_jit_alloc_exec`. I want to make sure I recall the key interactions there, especially what happens when the flag is set. That function is the core of how we actually get the executable memory. Need to keep that picture clear in my head. |
| 16/2 | 2026/07/16 13:12 | tool | read-file |
0mArgs:{
"File": "kernel/bpf/core.c",
"FirstLine": 1115,
"LineCount": 50
}Results: {
"Contents": "1115:\t\t\t}\n1116:\t\t}\n1117:\t\n1118:\t\treturn 0;\n1119:\t}\n1120:\t\n1121:\tvoid bpf_jit_uncharge_modmem(u32 size)\n1122:\t{\n1123:\t\tatomic_long_sub(size, \u0026bpf_jit_current);\n1124:\t}\n1125:\t\n1126:\tvoid *bpf_jit_alloc_exec(unsigned long size)\n1127:\t{\n1128:\t\treturn execmem_alloc(EXECMEM_BPF, size);\n1129:\t}\n1130:\t\n1131:\tvoid *bpf_jit_alloc_exec_rw(unsigned long size)\n1132:\t{\n1133:\t\treturn execmem_alloc_rw(EXECMEM_BPF, size);\n1134:\t}\n1135:\t\n1136:\tvoid bpf_jit_free_exec(void *addr)\n1137:\t{\n1138:\t\texecmem_free(addr);\n1139:\t}\n1140:\t\n1141:\tstruct bpf_binary_header *\n1142:\tbpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,\n1143:\t\t\t unsigned int alignment,\n1144:\t\t\t bpf_jit_fill_hole_t bpf_fill_ill_insns)\n1145:\t{\n1146:\t\tstruct bpf_binary_header *hdr;\n1147:\t\tu32 size, hole, start;\n1148:\t\n1149:\t\tWARN_ON_ONCE(!is_power_of_2(alignment) ||\n1150:\t\t\t alignment \u003e BPF_IMAGE_ALIGNMENT);\n1151:\t\n1152:\t\t/* Most of BPF filters are really small, but if some of them\n1153:\t\t * fill a page, allow at least 128 extra bytes to insert a\n1154:\t\t * random section of illegal instructions.\n1155:\t\t */\n1156:\t\tsize = round_up(proglen + sizeof(*hdr) + 128, PAGE_SIZE);\n1157:\t\n1158:\t\tif (bpf_jit_charge_modmem(size))\n1159:\t\t\treturn NULL;\n1160:\t\thdr = bpf_jit_alloc_exec(size);\n1161:\t\tif (!hdr) {\n1162:\t\t\tbpf_jit_uncharge_modmem(size);\n1163:\t\t\treturn NULL;\n1164:\t\t}\n"
} |
| 17/2 | 2026/07/16 13:12 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 11023 output: 23 thoughts: 286 Thoughts: **My Assessment of the Functional Changes** Okay, these changes seem solid – they're definitely functional and the code paths are reachable, which is crucial. My initial list of focus symbols is a good starting point: `bpf_prog_pack_alloc`, `alloc_new_pack`, `arch_bpf_trampoline_size`, `bpf_dispatcher_change_prog`, `bpf_jit_alloc_exec_rw`, and `bpf_jit_alloc_exec`. Wait a minute... thinking about it more, `bpf_jit_alloc_exec` and `bpf_jit_alloc_exec_rw` are pretty straightforward wrappers around `execmem_alloc` and `execmem_alloc_rw`. It might be more insightful to prioritize `bpf_prog_pack_alloc` and `alloc_new_pack` instead, as they're closer to the core allocation logic. `arch_bpf_trampoline_size` and `bpf_dispatcher_change_prog` are definitely relevant, and should be included on the list. Let's double-check the reachability of these key elements. I know `arch_bpf_trampoline_size` is embedded in the BPF trampoline logic. And `bpf_dispatcher_change_prog` plays a vital role in the BPF dispatcher logic, so those are confirmed as active components. I need to keep in mind the relevant configuration options that influence this area: `BPF_JIT`, `BPF_SYSCALL`, and `EXECMEM`. Let me quickly confirm that `EXECMEM` is actually a configurable option. |
| 18/2 | 2026/07/16 13:12 | tool | grepper |
0mArgs:{
"Expression": "config EXECMEM",
"PathPrefix": ""
}Results: {
"Output": "mm/Kconfig=1454=config IOMMU_MM_DATA\n--\nmm/Kconfig-1456-\nmm/Kconfig:1457:config EXECMEM\nmm/Kconfig-1458-\tbool\n"
} |
| 19/2 | 2026/07/16 13:13 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 11752 output: 26 thoughts: 27 Thoughts: Okay, here's my summary, in the first person, as requested, geared toward an expert audience: **Examining Configuration Options** Right, so I'm focusing on these system configurations. My initial thought is that `EXECMEM` – definitely, that's a known config, it's pretty clear. Now, I need to verify something else. My mental checklist dictates that I must confirm the status of `BPF_JIT`. Is it also configured, or do I need to investigate further? This is the core of what I am doing now. |
| 20/2 | 2026/07/16 13:13 | tool | grepper |
0mArgs:{
"Expression": "config BPF_JIT",
"PathPrefix": ""
}Results: {
"Output": "kernel/bpf/Kconfig=27=config BPF_SYSCALL\n--\nkernel/bpf/Kconfig-41-\nkernel/bpf/Kconfig:42:config BPF_JIT\nkernel/bpf/Kconfig-43-\tbool \"Enable BPF Just In Time compiler\"\n--\nkernel/bpf/Kconfig-57-\nkernel/bpf/Kconfig:58:config BPF_JIT_ALWAYS_ON\nkernel/bpf/Kconfig-59-\tbool \"Permanently enable BPF JIT and remove BPF interpreter\"\n--\nkernel/bpf/Kconfig-68-\nkernel/bpf/Kconfig:69:config BPF_JIT_DEFAULT_ON\nkernel/bpf/Kconfig-70-\tdef_bool ARCH_WANT_DEFAULT_BPF_JIT || BPF_JIT_ALWAYS_ON\n"
} |
| 21/2 | 2026/07/16 13:13 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 12148 output: 27 thoughts: 31 Thoughts: Okay, here's my attempt at summarizing those thoughts from a first-person, expert perspective, aiming for a fulsome rendering: **My BPF Config Consideration** Alright, so the first thing on my mind is confirming that `BPF_JIT` is indeed a configuration option, which is pretty fundamental to how things work. *Yes, confirmed; we know `BPF_JIT` is a config parameter. Let's move on*. Now, since we're diving into BPF configurations, the natural next step, *for me*, is to look at `BPF_SYSCALL`. I need to verify whether that's also exposed as a configurable option. It's often intertwined with the overall BPF setup, so understanding its status is key to evaluating the overall picture. I'll need to know whether I can modify it directly, or if it's implicitly enabled or disabled based on other settings. Knowing this is critical to proper BPF program operation, security and portability. |
| 22/2 | 2026/07/16 13:13 | tool | grepper |
0mArgs:{
"Expression": "config BPF_SYSCALL",
"PathPrefix": ""
}Results: {
"Output": "kernel/bpf/Kconfig=25=menu \"BPF subsystem\"\nkernel/bpf/Kconfig-26-\nkernel/bpf/Kconfig:27:config BPF_SYSCALL\nkernel/bpf/Kconfig-28-\tbool \"Enable bpf() system call\"\n"
} |
| 23/2 | 2026/07/16 13:13 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 12500 output: 175 thoughts: 205 Thoughts: **Analyzing BPF Configuration and Symbol Visibility** Okay, so I've confirmed that `BPF_SYSCALL` is indeed a configuration option, making the relevant configurations `BPF_JIT`, `BPF_SYSCALL`, and `EXECMEM`. My focus is on these symbols: `alloc_new_pack`, `bpf_prog_pack_alloc`, `arch_bpf_trampoline_size`, and `bpf_dispatcher_change_prog`. Let's start by checking the scope of these key symbols. I see that `alloc_new_pack` is static, defined within `kernel/bpf/core.c`. Good, got that. Now, I'm verifying that `bpf_prog_pack_alloc` is exported or global – confirmed, it's global. Following that, I'm checking `arch_bpf_trampoline_size`'s scope - it's global. And finally, I see that `bpf_dispatcher_change_prog` is also global. Alright, I've got a good understanding of the scope of these symbols now. I'll document my findings. |
| 24/2 | 2026/07/16 13:13 | tool | set-results |
0mArgs:{
"EnableConfigs": [
"BPF_JIT",
"BPF_SYSCALL",
"EXECMEM"
],
"FocusSymbols": [
"alloc_new_pack",
"bpf_prog_pack_alloc",
"arch_bpf_trampoline_size",
"bpf_dispatcher_change_prog"
],
"Reasoning": "The patch modifies BPF JIT memory allocation logic, introducing `bpf_jit_alloc_exec_rw` and updating `bpf_jit_alloc_exec` to use `execmem_alloc`. It also changes x86 BPF JIT memory initialization and updates BPF trampoline and dispatcher logic to use the new allocation methods. These are functional changes to reachable core BPF logic.",
"WorthFuzzing": true
}Results: {
"EnableConfigs": [
"BPF_JIT",
"BPF_SYSCALL",
"EXECMEM"
],
"FocusSymbols": [
"alloc_new_pack",
"bpf_prog_pack_alloc",
"arch_bpf_trampoline_size",
"bpf_dispatcher_change_prog"
],
"Reasoning": "The patch modifies BPF JIT memory allocation logic, introducing `bpf_jit_alloc_exec_rw` and updating `bpf_jit_alloc_exec` to use `execmem_alloc`. It also changes x86 BPF JIT memory initialization and updates BPF trampoline and dispatcher logic to use the new allocation methods. These are functional changes to reachable core BPF logic.",
"WorthFuzzing": true
} |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|