From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 98A223BA8E for ; Mon, 2 Jul 2018 14:40:07 -0400 (EDT) Received: by mail-qk0-x241.google.com with SMTP id a132-v6so9180930qkg.3 for ; Mon, 02 Jul 2018 11:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YNNkpn2Wovdup0NCfVg+TNl4w9oyOA3VjY5WifJ34bU=; b=qX+dhsv5e4U4pwcrqrFCs842OGCpa07HEiB67XfNk0j29uAuJZ/NUvGiZxkF2UdAC4 wWSD8fIkEOa5uG9i12taWPZziTNRlmvdMW5RGpfZ58Zl7SqOJLicFz1YNjaB25DmWdcc 6VcZ4dYwwLvMBnaOPXG/pWkmVwZpsGtqVxkpWANb9xsvIS4ByvqVO+NhWULpeSp4S1Th Eu0oaWudzMMTxFx5KsRQTAmWE383w1p3In8yzxEoDtTyFNYfqo4WrcJ+8kLb6DWrKWH+ ODUMlbNNw9rQ3y5F5l8RHReGCcjeflAj5B3XhvD9opZiGywlwwp0TzpuLjDthMxMmTA7 WpGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YNNkpn2Wovdup0NCfVg+TNl4w9oyOA3VjY5WifJ34bU=; b=hRYAbyAI3bq5jd94f6G3r8B6zlWk3+JS3hB3Q4lSU7udvfoJGyk2Pm4SXoxtJpbvjM 7F2c7c9h6psYULe4Dieq2hvUEKGH1QSIMQytj9z1dMVOPH09Wjff/qVlK8mCLJOp54Pc 3ozLgTAkvC5lfH7VSxuZ9JGzibRt66YOnDi9wHWlatnDZHbnUi9Ah8gbSLicjXySgFM6 GLu4rOExSqZ+d+gOKlSqXzw8eULSqsg+eyK0Ph0rMkNOMY+VrdVYb75FIsPEjsGbEEl4 dkhP+uvXreaRZwsdBCb/00SAvpnejDjSmlbip6JmFaPN73fDHN6wM3NtubI/QDH2EoOi wRqw== X-Gm-Message-State: APt69E0r+v24kGFYCaNgD9zuf+JXfLZfR2stL5A4AB78cj0t46BDdCbH /I8i8tWDuH0faEyA/dXs2fKMcYlNVT8qj7P+t8A= X-Google-Smtp-Source: AAOMgpdUHdpY8dmXsXHfHOmETd877UtiDAImJ2uOGyWw1IiQaU8fW7JODuPV0UIrQa0CWkWDaMkcItH/u+Uh+udq/mM= X-Received: by 2002:a37:2121:: with SMTP id h33-v6mr18042291qkh.319.1530556806940; Mon, 02 Jul 2018 11:40:06 -0700 (PDT) MIME-Version: 1.0 References: <6DF9A5E0-EFD5-4519-9889-BC0A7B9BD48E@darbyshire-bryant.me.uk> <1A8BA286-6B31-4581-86C9-6855AC28C245@heistp.net> <673EAD3F-AB09-4B90-88BB-5DCE0BD65534@heistp.net> <6FE8D434-01BE-41A1-BD6B-EFFD67AC8784@heistp.net> <94C9790F-E9BC-4D59-9845-17C305E4B910@darbyshire-bryant.me.uk> <17AF79A0-0213-44E3-95B9-62795A644A47@heistp.net> <87lgatj13k.fsf@toke.dk> <87fu11ipir.fsf@toke.dk> In-Reply-To: <87fu11ipir.fsf@toke.dk> From: Dave Taht Date: Mon, 2 Jul 2018 14:39:55 -0400 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Pete Heist , Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] Cake on openwrt - falling behind X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 18:40:08 -0000 On Mon, Jul 2, 2018 at 12:13 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Pete Heist writes: > > >> On Jul 2, 2018, at 2:03 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >> > >> Pete Heist writes: > >> > >>> But, um, I find it curious that tb[TCA_PAD] has valid looking values > >>> in it, and if I just go: > >>> > >>> tb[TCA_STATS2] =3D tb[TCA_PAD] > >>> > >>> right after parse_rtattr is called, I start getting tin stats printed > >>> that look valid. There should be zeroes or invalid values at > >>> tb[TCA_PAD], as that=E2=80=99s just supposed to be padding, right? > >> > >> Hmm, that's interesting. Sounds like you are on the right track. What > >> are the numerical values of TCA_STATS2 and TCA_PAD in the kernel and > >> iproute2, respectively? > > > > I never would=E2=80=99ve guessed they could be different when compiled = at once > > :) but true, there are at least five different versions of rtnetlink.h > > under build_dir based on their md5sums, and I see one belongs to > > iproute2-full. In all of those, it looks in the source like > > TCA_STATS2=3D7 and TCA_PAD=3D9. > > Aha! I think I figured out what is going on: > > The gen_stats facility will add an nlattr header at the beginning of the > qdisc stats, which is the toplevel TLV that contains all stats (and that > we put our stats inside). It stores a reference to this header, and when > all the per-qdisc callbacks have finished adding their stats, it goes > back and fixes up the length of the containing header. > > The problem is that on architectures that need padding, the padding TLV > is added *first*, which means that the nlattr pointer that is stored > before the callbacks are performed points to the padding TLV and not the > stats TLV. And so, when the header is fixed up, the result (from the > parser's perspective) is just a very big padding TLV. > > The options TLV is before the stats TLV, so the bug only occurs if the > options happen to have a length that means the stats will need padding. > Which is why messing with the number of options "fixes" the bug. > > 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? > > -Toke > > > @@ -77,8 +77,12 @@ gnet_stats_start_copy_compat(struct sk_buff *skb, int = type, int tc_stats_type, > d->lock =3D lock; > spin_lock_bh(lock); > } > - if (d->tail) > - return gnet_stats_copy(d, type, NULL, 0, padattr); > + if (d->tail) { > + int ret =3D gnet_stats_copy(d, type, NULL, 0, padattr); > + if (!ret) > + d->tail =3D ((struct nlattr *)skb_tail_pointer(sk= b)) - 1; > + return ret; > + } > > return 0; > } > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619