Hi, I run Omarchy 4.0.4 with the linux-omarchy 7.2.5-3 kernel, and I have a reproducible regression I would like to help track down. An eBPF-based security agent on my machine is stable on the stock Arch kernel and grows unbounded memory on linux-omarchy. I am writing to ask whether the kernel package's source, patches and config can be published or pointed to, because they are the one part of this I cannot inspect.

Since drafting this I have run the controlled test, and it points at the kernel. I rebooted onto the stock Arch kernel 7.2.3-arch1-3 and changed nothing else: same agent build, same configuration, same machine, same caps in place. The memory growth stopped completely. Measured over 30 minutes against thresholds fixed before the test, reclaim activity fell from 12,978 events per minute to zero and CPU from 2.033 cores to 0.065, with a control process confirming the harness was measuring the agent rather than the machine. Forty minutes in, cumulative swap use is still 0 bytes, against 10.77 GB on linux-omarchy under the identical software. That is the same machine and the same software on two kernels, which is why I am asking about the kernel specifically rather than filing a general bug against the agent. To be clear about what I am and am not claiming: I am not saying your kernel is defective. I cannot see its source, and that is precisely what I am asking for.

I want to lead with the second report, because it is what makes this more than one machine's problem. There is already an open issue against this kernel, omacom/omarchy#12131, reporting constant HDMI audio underruns on linux-omarchy 7.2.5 that do not occur on stock Arch 7.2.3. That is an independent reporter, a different symptom, and the same kernel transition, from 7.2.3-arch1-3 to linux-omarchy 7.2.5-3. Two unrelated regressions appearing across the same transition is why I think this is worth looking at the build rather than only at my agent.

In my case, the same machine ran the previous Arch kernel for 7.6 days with the same agent build and the same policy, and no memory problem became visible. The first instance of the agent after switching to linux-omarchy, the one started at boot, reached a peak of 24.6 GB of anonymous memory in about 34 hours, and its growth produces no error in its own logs. I also upgraded the agent's vendor to their newest build and tested it: it does not fix the leak, and swap grew further, from a maximum of 9.08 GB observed on the prior build to 21.41 GB on the new one, measured the same way on both sides. That does not prove the kernel is the cause, but it makes it less likely that the next release of their code alone resolves this, and it is why the kernel source is what I am asking for.

I also tried switching the agent's capture mode from eBPF to kprobe, the only other option it offers, from a clean stop. It engaged (the kernel-side BPF resources were fully torn down) and then collected nothing at all, on any of the three event sources it reports. Both capture mechanisms this agent can use now fail on this kernel, for opposite reasons: eBPF works and leaks without bound, kprobe does not work at all. That is the strongest single reason I have for suspecting the kernel's own tracing infrastructure, rather than the agent's code alone.

I compared the running kernel's configuration against the stock Arch kernel's configuration on the same machine, extracted from both packaged images: 122 option names differ out of roughly 10,600 set in each. Nothing in the differences would explain this: the allocator, memory cgroup, swap, transparent huge pages, KSM and compaction options are identical, and all 41 BPF, BTF and kprobe options are identical. No sanitizer is enabled. Where the two configs do differ, it is mostly that Omarchy turned debug code off and exposes extra hidden options. One limit on this comparison: the two kernels are also different upstream versions, 7.2.3 and 7.2.5, and I do not have a same-version Arch config to separate that version change from Omarchy's own choices, so this diff cannot fully rule out the version bump itself, only the specific categories above.

That is why the remaining candidate is your patches, and why I am asking for them. A patched mm, allocator or BPF path would not appear in the build configuration at all, so a config diff cannot clear it. I am not claiming the kernel is definitely at fault. I am saying it is the variable I cannot rule out, because its source is not available to me.

The request is narrow: please publish the linux-omarchy PKGBUILD, the patch set and the config, or point me at where they already live. I will do the debugging and share what I find, and I am not asking you to debug my agent.

One piece of context, and it is not a complaint. On my machine this kernel was installed automatically by Omarchy's own migration during the 4.0.3 to 4.0.4 update, using pacman's `--noconfirm` flag, and the boot order was changed to prefer it. Users are moved onto this kernel without choosing it, which is simply why it would help for the build to be inspectable. Thanks for reading.

---