Re: [Patch net v5 3/9] net_sched: Implement the right netem duplication behavior

[Cong Wang <xiyou.wangcong@gmail.com>]

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@gmail.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.

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.

Thanks,
Cong