From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id A0D3421F2B4 for ; Tue, 3 Nov 2015 09:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1446573095; bh=RzIGzvvzya4J7z62qyQXnSavpdlzn+7dRr+ribppWlk=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=fv1XDB5IStpHZq3a9JNOIcSOjFChKz0Gz7d6nNTr/DO2CHclla2vU6v1OUhxfFnSC Jk+40q8jdjPQd/dc+Q5gtqfMqus96N35OoKJgccyX26j8xD8Uwa9quzp/ZDkwfY4YA 8C6+9pf9uP82ALMCPAWRo/9dP9A3sSy4h21Qp0O8= Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id B305D4E6F14; Tue, 3 Nov 2015 18:51:34 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Jonathan Morton References: <87oafbnsqn.fsf@toke.dk> <5638B29D.9020503@darbyshire-bryant.me.uk> <87k2pzns29.fsf@toke.dk> <6F28B0F0-8333-4753-802E-BDDAC42CBC7B@gmail.com> <87oafbat54.fsf@toke.dk> Date: Tue, 03 Nov 2015 18:51:34 +0100 In-Reply-To: (Jonathan Morton's message of "Tue, 3 Nov 2015 19:32:10 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <877flzas49.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Correct 'change' behaviour X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 17:52:01 -0000 Jonathan Morton writes: >> On 3 Nov, 2015, at 19:29, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> Well, there's some evidence to suggest that this is not in fact the case: > > I would consider that a tc bug. Well, tc does seem to be doing the right thing: if (matches(*argv, "change") =3D=3D 0) return tc_qdisc_modify(RTM_NEWQDISC, 0, argc-1, argv+1); if (matches(*argv, "replace") =3D=3D 0) return tc_qdisc_modify(RTM_NEWQDISC, NLM_F_CREATE|NLM_F_REPLACE, argc-1, = argv+1); However, this comment in sch_api.c in the kernel seems to indicate that they are considered equivalent by the kernel: /* This magic test requires explanation. * * We know, that some child q is already * attached to this parent and have choice: * either to change it or to create/graft new one. * * 1. We are allowed to create/graft only * if CREATE and REPLACE flags are set. * * 2. If EXCL is set, requestor wanted to say, * that qdisc tcm_handle is not expected * to exist, so that we choose create/graft too. * * 3. The last case is when no flags are set. * Alas, it is sort of hole in API, we * cannot decide what to do unambiguously. * For now we select create/graft, if * user gave KIND, which does not match existing. */ but the comment doesn't seem to match the subsequent test: if ((n->nlmsg_flags & NLM_F_CREATE) && (n->nlmsg_flags & NLM_F_REPLACE) && ((n->nlmsg_flags & NLM_F_EXCL) || (tca[TCA_KIND] && nla_strcmp(tca[TCA_KIND], q->ops->id)))) goto create_n_graft; as best I can follow the logic in that function, it *should* actually get recreated when those flags are set. So why on earth are the values wrong? Memory initialisation problem? -Toke