From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; dkim=pass header.d=mojatatu.com header.i=@mojatatu.com header.a=rsa-sha256 header.s=google header.b=BKft1Y0k; arc=pass; dmarc=none Received: from mail-pz2-x0f.google.com (mail-pz2-x0f.google.com [IPv6:2607:f8b0:4864:3b::f]) by mail.toke.dk (Postfix) with ESMTPS id 88BCB16F91DE for ; Fri, 25 Sep 2026 13:28:05 +0200 (CEST) Received: by mail-pz2-x0f.google.com with SMTP id d2e1a72fcca58-85469a3490bso614200b3a.3 for ; Fri, 25 Sep 2026 04:28:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1790335683; cv=none; d=google.com; s=arc-20260327; b=GLhh24EY+zIPFAmXVDNt9MjVgeqC1umuxhJYJpDk6qmlpbxuyMoG1CDy93jTisfkOq 0P6mD9PjOCsi7MjC0BZ7bFei6KSaM8XDSHNu2bmadQ/JSEIve8jMeUgMw5SAAPlLQLrQ pQ4db94lJwD4I+SWsde8FAY9EihSB7AI1qLaH7gMx5UbZE+tiXbW77i6y7REhIE+nw3x gOGt4pFrNRlEtsdugqYIRFgQerYgIAEcpLsaEoB9xbuaqaDI2vhtcv6CGgr5MQH754AY uuzG5v0G8cNAuzuvSB41yuK4WUgkbKQcWxx2kIbxZjxXsYwh6AAmEF1y0aDplDYH5k2X pzBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=vT5/bjyJslLlUAwC6M+UJEZRf5B1FXMtJ5ZL61PS+Vk=; fh=QWmOlKhNwgw10B0af/r86VLuhvJ1nB434yg9q6zpsgc=; b=Zb7BQQ9R6ezNJ72qNmjRhuK5otweFV5Sp9VA4oh2HLj2l1ei2C/qNlXgTMcq5nQtZ/ MqNbR2TpE3Z9kocfC0+CI/tViW6a3YOkUdVL1+BvTrkzatOX/bOJqQwf/NvZDVt9U1wn 98K6bLvwT5QU3YUI7ZGwkcqf54Fhh43yl073kOzc875kNyvLiPMdtjJ6blo+qNi9c9Nq vJxtDXo+X7wcxPThj5ofHoJqB0tm1xEvA2F8fdnLBdYVQKvh3tMN8TWJw6s9qnadPeLT 6DsyYB821oJn6l8Kkoi9S/fin8elMgYupqojG8Zqa1iNmuitRy6xG2SD9k0xltQyUesp ySmw==; darn=lists.bufferbloat.net ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mojatatu.com; s=google; t=1790335683; x=1790940483; darn=lists.bufferbloat.net; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=vT5/bjyJslLlUAwC6M+UJEZRf5B1FXMtJ5ZL61PS+Vk=; b=BKft1Y0ka9ynREwHpWq+Ntf1x+KQaDgYrMQLvbO/lM2t7Pzfv9CNOlMPell2NzKpw/ Lc6vCDTn3ub0HCoq5V4FUVRVLu97AGoZjQeXPfvjYrGd0GIUHsL4v7CQhwAJtUAujetl 6yejjFMeqghIt4p03zK1uc3HXma3BTP+UgiEI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790335683; x=1790940483; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=vT5/bjyJslLlUAwC6M+UJEZRf5B1FXMtJ5ZL61PS+Vk=; b=t7Xpa5H1+Z/VcyK5rWbC3kP1/DfDv/6Ascz2bGItWyFu5NByGPZsUJPVJMn72HJjM+ DhVmb5E1fP9L+H34yLsB/Y9CFVmTz5AxOdgcLiokpxLJhIbOwBW/8zpqzSr9vBskNNB7 f3/BGGndmYpg95DCnQPsf8dHsB4Q06eAW8vKDwBHyY3Z2zYnY1DUHyF44vwPl8VqnsPz 9vy1HCO06P8lv6e8ZLO6qh4zPopcAd674jbiOOKve/61r94PYLnD5BYlIKTwNyG2mEVi mIN+aW0n5pZ0dFU4Atns87LUijGbv6PZY3taF1fFlpJ0t9aKmUwdApvgF6HAdj4rGTyD PyUQ== X-Forwarded-Encrypted: i=1; AKwUvBxlUBeamB8HONi4HiVcxZCV8uZ52ZMdYBG8h3F5bJgNpIaXToOrShoCwIiKIBtL2VWbgMsy@lists.bufferbloat.net X-Gm-Message-State: AFuF++lUqUFEerVPSbY01yUr5T1VfbEVsPi14JBCmpmUSg3AtIaFKYiD mqwKFEbmpHJAGqKfvIBhq9hun+AKFdPm9IT9+mH2TUb3Sl2PqjbmIYg30UOXJVVoYvku8n0oLnD RPdoybFOvkV8CKghPW9rbm+MzrH/g/4eUAj2wg8TO X-Gm-Gg: AYBFou2Jz/Ts4TuUcxP1lOHRqOyoD+YEcVvoPEZ5Lb5GcBSXiqM1YXF+r6RjdAskgRG IpIPdIc4OZgR+Ya4f2/qiGSHSBzzWWiPTPxAK/CvlOv28DofZz9jGW8im76rvBXKIODrmsw+wHW NhUgXwUKnIc/jt6x1gBQSXhypc36XK0CwS0/1brV+1egFQUdY4H8i0Hjx5/nYrxZTiIJ1JRqkdU hlP5/97mKHujoCpqPOVw8SE0YVqBtWAnUNhITfwRhlaoKZZBsjKgLBGZ2pKLYMnz9PLI1StJkcM oN7BzvnDetpYhDjAJKixJTQqaVCbSc7VipQwVjPAR/4GSHn3aKV68xKBJffqX+CheU4yUjFI2Fp R0wJzMbHCwC8FqvMMvU5fk7n7qcvW3THuCw== X-Received: by 2002:a05:6a00:301e:b0:87d:3894:197b with SMTP id d2e1a72fcca58-8802dd03c64mr1243578b3a.59.1790335683264; Fri, 25 Sep 2026 04:28:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jamal Hadi Salim Date: Fri, 25 Sep 2026 07:27:51 -0400 X-Gm-Features: AclHuK84b0y7F0HEqpezhYZXsPyeRFSkZ1qh_36ghb7v2lh-eAqUCd7laRHoWFo Message-ID: To: Eric Dumazet Cc: netdev@vger.kernel.org, =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , cake@lists.bufferbloat.net, Jiri Pirko , "David S . Miller" , Jakub Kicinski , Paolo Abeni , Simon Horman , Victor Nogueira , hybris , Sashiko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 6UBKVZ6YYSEMBHBHDLMMAWKARLLSDWYC X-Message-ID-Hash: 6UBKVZ6YYSEMBHBHDLMMAWKARLLSDWYC X-MailFrom: jhs@mojatatu.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Cake] Re: [PATCH net-next] net/sched: fq_codel, cake: widen backlogs to u64 List-Id: Cake - FQ_codel the next generation Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri, Sep 25, 2026 at 5:13=E2=80=AFAM Eric Dumazet = wrote: > > On Fri, Sep 25, 2026 at 10:54=E2=80=AFAM Jamal Hadi Salim wrote: > > > > This is a follow-up to commit 8f735d64382d ("net/sched: bound > > qdisc_pkt_len to prevent qdisc soft lockup"), which capped > > qdisc_pkt_len() at QDISC_PKT_LEN_MAX (1 MiB). That cap bounds the stab > > amplifier but leaves the per-flow backlog counter u32: > > fq_codel_enqueue() accumulates qdisc_pkt_len(skb) into q->backlogs[idx]= , > > so a flow can still accumulate 4096 packets of 1 MiB each and wrap the > > counter mod 2^32. After a wrap, fq_codel_drop() sees a tiny maxbacklog > > and drops from an almost-empty flow, and the dequeue-side subtractions > > corrupt the counter further. > > > > Widen the fq_codel backlogs table, the fat-flow scan (maxbacklog/len) a= nd > > the drop threshold to u64. fq_codel is not lockless: every writer runs > > under the root qdisc lock, so plain u64 arithmetic keeps the WRITE_ONCE > > publish / READ_ONCE-consume pattern. The dump path > > (fq_codel_dump_class_stats) stays a lockless stat-only read. > > > > CAKE accumulates the same generic qdisc_pkt_len(skb) into its per-flow > > b->backlogs[] and per-tin b->tin_backlog and consumes the values for > > longest-flow pruning (cake_heapify/cake_heapify_up) and for the shaper > > staleness check, so it shares the bug. Widen those counters and the hea= p > > comparison locals to u64; the class/tin stats keep exporting the low 32 > > bits through the unchanged uAPI fields. > > > > Conditions to recreate the bug: CAP_NET_ADMIN in a user namespace; > > CONFIG_NET_SCH_FQ_CODEL=3Dy. > > > > ip tuntap add tun0 mode tun > > ip link set tun0 txqueuelen 32 up > > ip addr add 10.99.0.1/24 dev tun0 > > tc qdisc add dev tun0 root handle 1: stab overhead 2000000000 \ > > fq_codel flows 1 limit 4200 ecn drop_batch 4096 > > # hold the tun fd open without reading (IFF_BACKPRESSURE) so the qdis= c > > # backlog persists, then send at least 4300 packets (the wrap starts > > # at 4096 resident; the over-limit drop that reads the wrapped > > # threshold fires past the 4200 limit): backlogs[0] wraps at 4096 x > > # 1 MiB and the fat-flow threshold reads the wrapped value. > > > > With a 1 MiB qdisc_pkt_len cap the counter wraps at 4096 resident > > packets. At limit 4200 the first over-limit enqueue (the 4201st) sees a > > wrapped 105 MiB (half-backlog threshold 52 MiB, a ~52 packet drop burst= ), > > where the u64 counter sees 4201 MiB (threshold 2100 MiB, a ~2100 packet > > drop burst). > > > > Reported-by: Sashiko (nipa) > > Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260818101= 130.16203-1-jhs@mojatatu.com > > Link: https://lore.kernel.org/netdev/20260818101130.16203-1-jhs@mojatat= u.com/ > > Tested-by: hybris > > Signed-off-by: Jamal Hadi Salim > > --- > > This makes no sense. > As absurd as it looks that code is reachable ;-> > These qdisc have been developped to address bufferbloat issues. > > Storing 4GB in a qdisc is absolutely insane. > The counter wrap is not because we stored 4GB, rather it is because "tc .. stab overhead ..." inflates qdisc_pkt_len() for a 64B pkt to 1MB. So ~4K packets (put in other words a few "real" KB) makes that backlog[0] cross 2^32. Result is pruning the wrong flow.. > Let's drop at enqueue if the current backlog is approaching 4GB (this > can later be a new config/attribute in net-next) Note, this is net-next already. Enqueue is fast path - are you ok with that= ? cheers, jamal