[Cake] Correct 'change' behaviour
toke at toke.dk
Tue Nov 3 12:51:34 EST 2015
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) ||
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?
More information about the Cake