From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; dkim=none; arc=none (Message is not ARC signed); dmarc=fail (Used From Domain Record) header.from=toke.dk policy.dmarc=none From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Jakub Kicinski , Samuel Moelius Cc: Jamal Hadi Salim , Jiri Pirko , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , "moderated list:CAKE QDISC" , "open list:TC subsystem" , open list In-Reply-To: <20260613142626.1b2183eb@kernel.org> References: <20260609232935.1602659.8545fdb04fbe.cake-overhead-underflow@trailofbits.com> <20260613142626.1b2183eb@kernel.org> Date: Mon, 15 Jun 2026 13:21:12 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87wlw0gic7.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Message-ID-Hash: HZSJVQWPECFJD4EVJHSFXL7MI37AVPIZ X-Message-ID-Hash: HZSJVQWPECFJD4EVJHSFXL7MI37AVPIZ X-MailFrom: toke@toke.dk 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 v2] net/sched: cake: reject overhead values that underflow length List-Id: Cake - FQ_codel the next generation Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Jakub Kicinski writes: > On Tue, 9 Jun 2026 23:29:36 +0000 Samuel Moelius wrote: >> +static const struct netlink_range_validation_signed cake_overhead_range = { >> + .min = -64, >> + .max = 256, > > Both Sashiko's complain - these values are neither safe nor sufficient. > > How was the -64 chosen? It looks suspiciously close the min ethernet > frame length. But in that case (a) FCS doesn't count so 60, and > (b) even IPv4 TCP packets can be shorter (at qdisc layer) than 64B > leading to underflow... > > I see min rate in cake is 64 but I don't see any other meaning of the > 64 literal. > > Toke, WDYT? Should we use a smaller constant (ETH_HLEN?) or do the > check on the datapath? Hmm, we do actually have a check on the datapath already, so just amending that like the second Sashiko suggestion should add no additional runtime overhead. In which case there's no reason to add the policy at all, I suppose. So basically: diff --git i/net/sched/sch_cake.c w/net/sched/sch_cake.c index a3c185505afc..259e4b8d09c5 100644 --- i/net/sched/sch_cake.c +++ w/net/sched/sch_cake.c @@ -1389,10 +1389,7 @@ static u32 cake_calc_overhead(struct cake_sched_data *qd, u32 len, u32 off) if (qd->min_netlen > len) WRITE_ONCE(qd->min_netlen, len); - len += q->rate_overhead; - - if (len < q->rate_mpu) - len = q->rate_mpu; + len = max((s32)len + q->rate_overhead, (s32)q->rate_mpu); if (q->atm_mode == CAKE_ATM_ATM) { len += 47; (Sashiko suggests using max_t, but that seems a bit redundant when there's already casts in the operands, no?) -Toke