[Cake] Correct 'change' behaviour

[Toke Høiland-Jørgensen]

Jonathan Morton <chromatix99 at gmail.com> writes:

>> On 3 Nov, 2015, at 19:29, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>> 
>> 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") == 0)
		return tc_qdisc_modify(RTM_NEWQDISC, 0, argc-1, argv+1);
	if (matches(*argv, "replace") == 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