Jonathan Morton <[email protected]> writes: >> On 12 Aug, 2018, at 1:23 pm, Pete Heist <[email protected]> wrote: >> >> One more thing to add to this, when working with another bpf filter which is >> relatively similar to this simple one (although has some more innocuous >> looking code like map lookups and read-only operations on the skb) sometimes >> the attached is suddenly and repeatedly sent to both syslog and kern.log >> until the disk fills up... > >> Aug 12 09:57:25 ubuntu kernel: [ 2408.152975] WARNING: CPU: 3 PID: 2304 at >> /home/a/src/sch_cake/sch_cake.c:2094 cake_dequeue+0x791/0xc70 [sch_cake] > >> WARN_ON(host_load > CAKE_QUEUES); > > Yeah, something is going seriously wrong here. It shouldn't be > possible for that warning to trigger; if it is, then Cake's internal > data structures are being corrupted somehow. > > But Cake doesn't directly read tc_classid from an skb. So what could > it be influencing?
Yes it does; setting tc_classid is one way to set the flow class that is read by the call to tcf_classify(). I guess the problem is that cake_hash() is bypassed, so the *host_refcnt variables are not incremented. There's been another report of the same issue on github; haven't had time to look into it yet, but I guess this is the reason... I guess there are two options here; either always run the hashing algorithm to select the host hashes, or make sure the srchost/dsthost fields are set to 0 when tc classification is used. I think the latter is the better approach; but I'm not sure if it's enough to just set the fields to 0? There seem to be unconditional decrements of the refcnts in multiple places? -Toke _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
