Thread (26 messages) 26 messages, 7 authors, 2026-02-28

Re: [PATCH net 0/6] net/sched: Fix packet loops in mirred and netem

From: Cong Wang <hidden>
Date: 2026-01-15 20:17:02
Also in: netfilter-devel

On Wed, Jan 14, 2026 at 8:34 AM Jamal Hadi Salim [off-list ref] wrote:
On Tue, Jan 13, 2026 at 3:10 PM Cong Wang [off-list ref] wrote:
quoted
On Sun, Jan 11, 2026 at 8:40 AM Jamal Hadi Salim [off-list ref] wrote:
quoted

We introduce a 2-bit global skb->ttl counter.Patch #1 describes how we puti
together those bits. Patches #2 and patch #5 use these bits.
I added Fixes tags to patch #1 in case it is useful for backporting.
Patch #3 and #4 revert William's earlier netem commits. Patch #6 introduces
tdc test cases.
3 reasons why this patchset should be rejected:

1) It increases sk_buff size potentially by 1 byte with minimal config
All distro vendors turn all options. So no change in size happens.
Regardless, it's a non-arguement there is no way to resolve the mirred
issue without global state.
It's a twofer - fixing mirred and netem.
This makes little sense, because otherwise people could easily add:

struct sk_buff {
....
#ifdef CONFIG_NOT_ENABLED_BY_DEFAULT
  struct a_huge_field very_big;
#endif
};

What's the boundary?
quoted
2) Infinite loop is the symptom caused by enqueuing to the root qdisc,
fixing the infinite loop itself is fixing the symptom and covering up the
root cause deeper.
The behavior of sending to the root has been around for ~20 years.
So what?
I just saw your patches - do you mind explaining why you didnt Cc me on them?
You were the one who refused anyone's feedback on your broken and
hard-coded policy in the kernel.

Please enlighten me on how we should talk to a person who refused
any feedback? More importantly, why should we waste time on that?

BTW, I am sure you are on netdev.
quoted
3) Using skb->ttl makes netem duplication behavior less predictable
for users. With a TTL-based approach, the duplication depth is limited
by a kernel-internal constant that is invisible to userspace. Users
configuring nested netem hierarchies cannot determine from tc
commands alone whether their packets will be duplicated at each
stage or silently pass through when TTL is exhausted.
The patch is not using the ttl as a counter for netem, it's being
treated as boolean (just like your patch is doing). We are only using
this as a counter for the mirred loop use case.
This does not change this argument for a bit. It is still hidden
and users are still unable to figure it out (even before your patch).

Regards,
Cong
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help