[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <iEqzQsC-O2kAXqH1_58I59DIhBjRgebyGym2ZqyMEI3DaMtgsKSYR0KUsbxj5xqvfzf-4XzpM8dXvATHJhVVw3NedRdL3j1FJaqiXPlNWeE=@willsroot.io>
Date: Wed, 21 May 2025 14:03:36 +0000
From: William Liu <will@...lsroot.io>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Savy <savy@...t3mfailure.io>, Cong Wang <xiyou.wangcong@...il.com>, Victor Nogueira <victor@...atatu.com>, Pedro Tammela <pctammela@...atatu.com>, Paolo Abeni <pabeni@...hat.com>, Jakub Kicinski <kuba@...nel.org>, Stephen Hemminger <stephen@...workplumber.org>, Davide Caratti <dcaratti@...hat.com>
Subject: Re: [BUG] net/sched: Soft Lockup/Task Hang and OOM Loop in netem_dequeue
On Wednesday, May 21st, 2025 at 11:06 AM, Jamal Hadi Salim <jhs@...atatu.com> wrote:
> I am afraid using bits on the skb will not go well around here - and
> zero chance if you are using those bits for a one-off like netem.
> Take a look at net/sched/act_mirred.c for a more "acceptable"
> solution, see use of mirred_nest_level.
>
Ah ok, thank you for the suggestion. We will take a look at that then.
> Not that it matters but I dont understand why you moved the skb2 check
> around. Was that resolving anything meaningful?
>
> cheers,
> jamal
>
Yes - otherwise the limit value of the qdisc isn't properly respected and can go over by one due to duplication. The limit check happens before both the duplication and the skb enqueue, so after duplication, that limit check would be stale for the original enqueue.
Best,
Will
Powered by blists - more mailing lists