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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1606281717140.6874@cbobk.fhfr.pm>
Date:	Tue, 28 Jun 2016 17:19:13 +0200 (CEST)
From:	Jiri Kosina <jikos@...nel.org>
To:	Eric Dumazet <eric.dumazet@...il.com>
cc:	Jamal Hadi Salim <jhs@...atatu.com>, Phil Sutter <phil@....cc>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Fri, 15 Apr 2016, Eric Dumazet wrote:

> > TBF is probably a bad example because it started life as a classless 
> > qdisc. There was only one built-in fifo queue that was shaped. Then 
> > someone made it classful and changed this behavior. To me it sounds 
> > reasonable to have the default behavior restored. At minimal 
> > consistency.
> 
> 
> Then you need to save the initial qdisc (bfifo for TBF) in a special
> place, to make sure the delete operation is guaranteed to succeed.
> 
> Or fail the delete if the bfifo can not be allocated.
> 
> I can tell that determinism if far more interesting than usability for
> some users occasionally playing with tc.

BTW, I've started to actually work on fixing this, and I've noticed that 
TBF behavior actually violates what's stated in pfifo_fast manpage:

==========
        Whenever  an  interface is created, the pfifo_fast qdisc is 
	automatically used as a queue. If another qdisc is
	attached, it preempts the default pfifo_fast, which automatically 
	returns to function when an  existing  qdisc is detached.

	In this sense this qdisc is magic, and unlike other qdiscs.
==========

-- 
Jiri Kosina
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ