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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAM0EoMmd5L+6vnHR98i4i+rwYrwqZbAAxxBVEZ60WtD9nNKqjw@mail.gmail.com>
Date: Fri, 16 Jan 2026 10:04:54 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Cong Wang <xiyou.wangcong@...il.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, 
	pabeni@...hat.com, horms@...nel.org, andrew+netdev@...n.ch, 
	netdev@...r.kernel.org, jiri@...nulli.us, victor@...atatu.com, 
	dcaratti@...hat.com, lariel@...dia.com, daniel@...earbox.net, 
	pablo@...filter.org, kadlec@...filter.org, fw@...len.de, phil@....cc, 
	netfilter-devel@...r.kernel.org, coreteam@...filter.org, 
	zyc199902@...omail.cn, lrGerlinde@...lfence.com, jschung2@...ton.me, 
	William Liu <will@...lsroot.io>, Savy <savy@...t3mfailure.io>
Subject: Re: [PATCH net 0/6] net/sched: Fix packet loops in mirred and netem

On Thu, Jan 15, 2026 at 3:17 PM Cong Wang <xiyou.wangcong@...il.com> wrote:
>
> On Wed, Jan 14, 2026 at 8:34 AM Jamal Hadi Salim <jhs@...atatu.com> wrote:
> >
> > On Tue, Jan 13, 2026 at 3:10 PM Cong Wang <xiyou.wangcong@...il.com> wrote:
> > >
> > > On Sun, Jan 11, 2026 at 8:40 AM Jamal Hadi Salim <jhs@...atatu.com> wrote:
> > > >
> > > >
> > > > 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?
>
> >
> > > 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?
>

Let's say you have a filter and action (or ebpf program) that needs to
see every packet as part of its setup. That filter is attached to the
root qdisc. The filter is no longer seeing the duplicated packets.


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

Ok, I think ive had it with you. Your claim is laughable at best. I am
the one who wasnt taking feedback? Seriously? you literally scared
people who could be potentially contributing to tc by your drama. You
received feedback on all variations of your four-to-five patche  and
you didnt listen to any. It would be a good idea to use an AI to
summarize mailing list discussions and i hope such discussions can be
captured as part of commits.

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

I read netdev emails only when i have time. Emails directed at me will
be read much much sooner.
We have rules: if you send patches, you must copy every stakeholder.
This cant just  be based on your emotions on when this rule applies or
not. Please make sure you do this going forward.

> >
> > > 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).
>

I am trying to make sense of what you are saying.
The ttl being boolean is exactly as in your patch with cb.
The goal of your patch should be to stop the loop. You are making an
additional change so that your cb changes work and you are implying
that the user can only understand it if better you made these extra
changes?

cheers,
jamal