Created attachment 284581 [details] BUG/Oops: kernel 5.2.6/x86_64 Overview: ========= Several uses of "tc filter .. action xt" work as expected and also allow final qdisc/filter deletion: e.g. xt_DSCP and xt_CLASSIFY. However, trying to delete a qdisc/filter using xt_CONNMARK results in a kernel oops or hang/crash on all platforms and kernel versions tested. Steps to Reproduce: =================== # tc qdisc add dev lo clsact # tc filter add dev lo egress protocol ip matchall action xt -j CONNMARK --save-mark # tc qdisc del dev lo clsact <Kernel Oops> Systems Tested: =============== Ubuntu 18.04 LTS (mainline kernel 5.2.6/x86_64, iptables 1.6.1, iproute2 4.15) (Kernel build: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2.6/) Ubuntu 18.04 LTS (distro kernel 4.15/x86_64, iptables 1.6.1, iproute2 4.15) OpenWrt master, r10666-fc5d46dc62 (kernel 4.19.62, mips32_be, iptables 1.8.3, iproute2 5.0.0) OpenWrt 19.07, r10324-8bf8de95a2 (kernel 4.14.133, armv7l, iptables 1.8.3, iproute2 5.0.0) Kernel Logs: ============ The clearest call traces are from the Ubuntu systems, and are attached.
Created attachment 284583 [details] BUG/Oops: kernel 4.15/x86_64
Created attachment 284589 [details] Proposed fix We forgot to initialize the net pointer... Can you test the attached patch? Note this patch is generated against latest net tree, so if you apply it to an older kernel, you probably have to adjust it manually (some of the files it patches don't exist on older kernels). Thanks.
I managed to apply the patch with minimal tweaking to a 4.19.66 LTS kernel (OpenWrt) and retested. The expected functionality was OK and no BUG/Oops was observed when deleting either the tc filter or qdisc, so I think the proposed fix is correct. Also, would the fix automatically get backported to the stable LTS kernel branches 4.19.x, 4.14.x, etc? Or is there some further process to follow? Thanks so much for looking into this.
Thanks for testing it! I just sent out the patch formally with you copied. The networking subsystem maintainer will take care of the backports to stable releases.
As another point of confirmation, I also applied a tweaked patch to an OpenWrt 4.14.138 LTS kernel with successful results. Thanks for clarifying the backports.
Confirmed that this has been fixed in upstream master and the reported LTS branches.