Hello Philip, On Fri, Oct 30, 2026 at 08:00:31AM +0100, Philip Dodd wrote: > On 29/10/2026 11:29, Florian Westphal wrote: > > Uwe Kleine-König <[email protected]> wrote: > > > this is about a bug report filed against the Debian 7.2.12 kernel. Further > > > context can be found at https://bugs.debian.org/1149525. > > > > > > Note this is an arm64 machine, and the problem doesn't reproduce on 7.3. > > > > > > On Mon, Oct 26, 2026 at 08:36:01AM +0100, Philip Dodd wrote: > > > > 7.2.12+deb14-arm64 is affected in the same way, reproduced by just > > > > loading > > > > the nf_conntrack module shortly after boot. > > > > > > > > After the failure: > > > > nf_conntrack module use count: 0 > > > > net.netfilter.nf_conntrack_count: 0 > > > > nf_conntrack hashsize: 65536 > > > > /proc/sys/kernel/tainted: 128 > > > > > > > > No nf_nat or xt_* modules were loaded. > > If thats the case, why is there a conntrack entry in the first place? > > Is 'enable_hooks' modparam used? > > No, I'm not explicitly using |enable_hooks|. Simply running |sudo modprobe > nf_conntrack|is sufficient to trigger the oops. > > For context, I originally encountered the oops shortly after boot during > normal operation. I narrowed it down to occurring shortly after > |tailscaled|started, but subsequently found that even with Tailscale > disabled, simply loading |nf_conntrack|triggers the same oops almost > immediately; and since I've reproduced this on all the 7.2.x kernels I've > tested (the versions mentioned earlier in the Debian bug report), but also > kernels compiled directly from upstream sources. > > The same |modprobe nf_conntrack|command does not trigger the oops on 7.1.x > or 7.3.x kernels; Prior to upgrading to the first 7.2.x kernel, this host > had also been running Tailscale with |nf_conntrack|loaded for weeks (at > least) without any problems and yesterday, I installed the 7.3.x kernel > packages from Debian experimental and ran Tailscale for an extended period > without encountering any issues.
Given that you know how to compile kernels for your machine, can you please test plain 7.2? Depending on that being good or bad, I'd ask you to do a bisection either between 7.2 and 7.2.12 (to find the breaking commit) or between 7.2 and 7.3 (to find the fixing commit). If you report the state of 7.2, I can prepare more detailed instruction for the bisect if needed. Thanks Uwe
signature.asc
Description: PGP signature
