From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 40A863BA8E for ; Mon, 2 Jul 2018 15:27:39 -0400 (EDT) Received: by mail-qk0-x244.google.com with SMTP id c192-v6so3040050qkg.12 for ; Mon, 02 Jul 2018 12:27:39 -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=VN+euS9WrRZn0Ug4xvZSi0AgETqoQa0Mqe+19WPLvIk=; b=CfJZpXnE+G7vpUCoaEK7JtOa+GQsB8VPfdc3NRDZw4djUxBWXrhpN/us8v1eTnKjS/ lOulk+6F/M4QazAccbjbqWpWM/JKpOTQkUMp5g/YnvnVzlzV7QjHvBnSD/eoTSDHukP/ 0jksQ5XmYGYJXjESzsYCHvMHPezp7HgZmkglHjyEyI/KIxmdiGucdE0AfLyy1JsEx3yi YYrJWbPrOW6e7NU3AQ+IvykkFNNj/kUKidqCt1OCpyr8WCTDIM2E83mBURjRSSaCpD0x giRfM974eKf9Xb8X/PPkdAhiuFrnCWwUeGZaVvLG6jGCrdsXBCpnA5v+7FODmlk+oLV4 HfOA== 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=VN+euS9WrRZn0Ug4xvZSi0AgETqoQa0Mqe+19WPLvIk=; b=T1wuz4cAANfYty4w4a/SzoDst4SgaEVJTCkQsEASgZHten7UOdcZEjZ6X3Kn4FlmBs mmhZsUeSuM/OD28GznNBk/GT2me23blSfp6M80K3tOv9ncqvo+CEr7JbUau86c8yhCl5 wxG6KxJGVtmT/DftkqhLQHr6iKnuR8KCD7qe5TE98zrZ8F+08qxprjv0bABw70v8oJGF SaLA3gZ9sWybnCBq+vHd0hZxd+YGQo5GTbsLN0fsNnB5d1bUJXLbNOGmb9oGiaQ19G6E pKTCQ2c82znnPv+TW61S6wLUCIVkUE+nAFYahOvzeG2Ttxg8XI2G42LQLiaf1PWdBMMv OtaQ== X-Gm-Message-State: APt69E3+wxAiSpdJoCyFOWMeOR7qdvInAxRZUXxzXl0/38KJa376jdXq NMltgvaTbBVf4Aq+Y/r4ai/2RXN5upzOHi2CtOA= X-Google-Smtp-Source: AAOMgpd6WFxLuyGSeDVOb7NW+5WgEhUmfPyrRJNTC7Cgi+qdueFQ5YLhZAyGIMEzMCBK3ff+NCccMCveys/TxwqkM58= X-Received: by 2002:a37:c40d:: with SMTP id d13-v6mr22861472qki.190.1530559658847; Mon, 02 Jul 2018 12:27:38 -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> <9F0353E5-D191-492A-9413-AA6BD03DD4C6@darbyshire-bryant.me.uk> <877emdigqe.fsf@toke.dk> In-Reply-To: <877emdigqe.fsf@toke.dk> From: Dave Taht Date: Mon, 2 Jul 2018 12:27:26 -0700 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Kevin Darbyshire-Bryant , 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 19:27:39 -0000 On Mon, Jul 2, 2018 at 12:23 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Kevin Darbyshire-Bryant writes: > > >> On 2 Jul 2018, at 19:39, Dave Taht wrote: > >> > >>> > >> > >> 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? > > > > If I understand correctly: This will only be a problem on > > architectures that require alignment of 64 bit values to 8 byte > > boundaries which is achieved by padding the structure by a dummy (4 > > byte) value if required. So to hit this bug we need kernel symbol > > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS undefined *and* we need a > > netlink stats structure that needs a 4 byte dummy pad value to align > > to 8 bytes. Of the architectures tested, MIPS is the only one that > > DOES NOT set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS and thus may be > > exposed to the bug. > > > > arm sets CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS and thus no padding is > > ever required/added, thus pointers always point to the correct data > > location. > > Yup, exactly. This has always been broken on MIPS, I assume, but because > most other qdiscs send their stats output as a serialised struct, tc > just automatically falls back to the legacy data format, and no one has > noticed. But because we switched to sending each stat as an individual > netlink attribute (and thus no fallback legacy stats struct), we expose > the bug... Well, if you wrap that patch in #ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS bla #endif I guess I'd sleep better but I do generally get nervous when arbitrarily subtracting something from a pointer > > -Toke --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619