Message-ID: <JgkxCYimi4ZuZPHfXoMUgiecvZ0AKYxbIhqPQZwXcE4yC9nYnfproH5yrmQETZUo55NOjj5Q9_bOFJbWI351PFvc9wv3xiY_0Ic9AAsO1Ak=@willsroot.io>
Date: Wed, 26 Nov 2025 22:43:07 +0000
From: William Liu <will@...lsroot.io>
To: Cong Wang <xiyou.wangcong@...il.com>
Cc: netdev@...r.kernel.org, stephen@...workplumber.org, kuba@...nel.org, Savino Dicanosa <savy@...t3mfailure.io>, Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: [Patch net v5 3/9] net_sched: Implement the right netem duplication behavior

On Wednesday, November 26th, 2025 at 10:08 PM, Cong Wang <xiyou.wangcong@...il.com> wrote:

> 
> 
> Hi William,
> 
> On Wed, Nov 26, 2025 at 08:30:21PM +0000, William Liu wrote:
> 
> > On Wednesday, November 26th, 2025 at 7:53 PM, Cong Wang xiyou.wangcong@...il.com wrote:
> > 
> > > In the old behavior, duplicated packets were sent back to the root qdisc,
> > > which could create dangerous infinite loops in hierarchical setups -
> > > imagine a scenario where each level of a multi-stage netem hierarchy kept
> > > feeding duplicates back to the top, potentially causing system instability
> > > or resource exhaustion.
> > > 
> > > The new behavior elegantly solves this by enqueueing duplicates to the same
> > > qdisc that created them, ensuring that packet duplication occurs exactly
> > > once per netem stage in a controlled, predictable manner. This change
> > > enables users to safely construct complex network emulation scenarios using
> > > netem hierarchies (like the 4x multiplication demonstrated in testing)
> > > without worrying about runaway packet generation, while still preserving
> > > the intended duplication effects.
> > > 
> > > Another advantage of this approach is that it eliminates the enqueue reentrant
> > > behaviour which triggered many vulnerabilities. See the last patch in this
> > > patchset which updates the test cases for such vulnerabilities.
> > > 
> > > Now users can confidently chain multiple netem qdiscs together to achieve
> > > sophisticated network impairment combinations, knowing that each stage will
> > > apply its effects exactly once to the packet flow, making network testing
> > > scenarios more reliable and results more deterministic.
> 
> 
> 
> Thanks for your quick response.
> 
> > Cong, this approach has an issue we previously raised - please refer to [2]. I re-posted the summary of the issues with the various other approaches in [3] just 2 days ago in a thread with you on it. As both Jamal and Stephen have pointed out, this breaks expected user behavior as well, and the enqueuing at root was done for the sake of proper accounting and rate limit semantics. You pointed out that this doesn't violate manpage semantics, but this is still changing long-term user behavior. It doesn't make sense imo to change one longtime user behavior for another.
> 
> 
> If you have a better standard than man page, please kindly point it out.
> I am happy to follow.
> 
> I think we both agree it should not be either my standard or anyone's
> personal stardard, this is why I use man page as a neutral and reasonable
> stardard.
> 
> If you disagree man page is reasonable, please offer a better one for me
> to follow. I am very open, I just simply don't know anything better than
> man page.

I agree that your change does not violate manpage semantics. This was the original fix I suggested from the beginning, though other maintainers pointed out the issue that I am relaying.

As I wrote in my previous email, "as both Jamal and Stephen have pointed out, this breaks expected user behavior as well, and the enqueuing at root was done for the sake of proper accounting and rate limit semantics."

The previous netem fix changed user behavior that did not violate the manpage (to my knowledge). This one is the same - you are fixing one user behavior break with another. Both are cases of Hyrum's law.

> 
> Sorry for my ignorance. Please help me out. :)
> 
> > Jamal suggested a really reasonable fix with tc_skb_ext - can we please take a look at its soundness and attempt that approach? No user behavior would be affected in that case.
> 
> 
> As I already explained, tc_skb_ext is for cross-layer, in this specific
> case, we don't cross layers, the skb is immediately queued to the same
> layer before others.
> 
> Could you please kindly explain why you still believe tc_skb_ext is
> better? I am very open to your thoughts, please enlighten me here.
> 

Yes, if we re-enqueue the packet to the same netem qdisc, we don't need this, but that changes expected user behavior and may introduce additional correctness issues pointed out above.

If understood Jamal correctly, tc_skb_ext allows us to maintain both the re-entrant at root behavior AND prevent DOS.

I hope you can understand I am trying to relay problems other maintainers have pointed out repeatedly; I personally don't have a strong stake in this.

> Thanks,
> Cong

Powered by blists - more mailing lists