lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <87lhadn5gm.fsf@toke.dk>
Date:	Wed, 04 Nov 2015 16:34:49 +0100
From:	Toke Høiland-Jørgensen <toke@...e.dk>
To:	netdev@...r.kernel.org
Cc:	cake@...ts.bufferbloat.net
Subject: Expected behaviour of `tc qdisc replace`?

Hi

I recently noticed that the behaviour of `tc qdisc replace` differs
depending on whether the qdisc being replaced is of the same kind as the
replacement. I.e.:

# tc qdisc del dev eno1 root
# tc qdisc replace dev eno1 root fq_codel target 100ms interval 200ms
# tc qdisc replace dev eno1 root fq_codel target 5ms                 
# tc qdisc
qdisc fq_codel 8007: dev eno1 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 200.0ms ecn 
# tc qdisc del dev eno1 root                                         
# tc qdisc replace dev eno1 root fq_codel target 5ms
# tc qdisc                                          
qdisc fq_codel 8008: dev eno1 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn 

Notice the difference in interval between the two output lines from tc.

Now, according to the tc man page, `tc qdisc replace` "Performs a nearly
atomic remove/add on an existing node id." In which case I would expect
it to *not* retain settings from the previous configuration.

So my question is: is this a bug, or is it expected behaviour? And if
the latter, what is the difference between `tc qdisc replace` and `tc
qdisc change` then supposed to be?

-Toke
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ