[Cake] Cake on openwrt - falling behind

[Pete Heist]

> On Jul 2, 2018, at 8:39 PM, Dave Taht <dave.taht at gmail.com> wrote:
> 
> On Mon, Jul 2, 2018 at 12:13 PM Toke Høiland-Jørgensen <toke at toke.dk <mailto:toke at toke.dk>> wrote:
>> 
>> Could you try applying the patch below (to the kernel) and see if that
>> resolves the issue, please?
> 
> This seems like it will introduce problems with stuff that isn't or is
> legitimately broken in the first place, pointing to potentially random
> data in the wrong place.
> 
> would a workaround be adding more padding to the cake stats output so
> it's always even?
> 
> why does it work as written on arm?

I doubt this, but what if someone else conditionally padded their custom stats in response? Personally I’d say get it right in the kernel and “make them fix their stuff”, but does anyone have visibility on that?

After re-reading Toke’s explanation I see now why tb[TCA_PAD] points to right before TCA_STATS2. That’s where the padding is. :) I was only generally wondering if a padding pointer should point to anything.

>> 
>> -Toke
>> 
>> 
>> @@ -77,8 +77,12 @@ gnet_stats_start_copy_compat(struct sk_buff *skb, int type, int tc_stats_type,
>>                d->lock = lock;
>>                spin_lock_bh(lock);
>>        }
>> -       if (d->tail)
>> -               return gnet_stats_copy(d, type, NULL, 0, padattr);
>> +       if (d->tail) {
>> +               int ret = gnet_stats_copy(d, type, NULL, 0, padattr);
>> +               if (!ret)
>> +                       d->tail = ((struct nlattr *)skb_tail_pointer(skb)) - 1;
>> +               return ret;
>> +       }
>> 
>>        return 0;
>> }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20180702/ca8165b0/attachment.html>