> On Jul 2, 2018, at 8:39 PM, Dave Taht <[email protected]> wrote:
>
> On Mon, Jul 2, 2018 at 12:13 PM Toke Høiland-Jørgensen <[email protected]
> <mailto:[email protected]>> 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;
>> }
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
