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: <20161021.110333.1897572143781385600.davem@davemloft.net>
Date:   Fri, 21 Oct 2016 11:03:33 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     eric.dumazet@...il.com
Cc:     jikos@...nel.org, jhs@...atatu.com, phil@....cc,
        xiyou.wangcong@...il.com, daniel@...earbox.net,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] net: sched: make default fifo qdiscs appear in the dump

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Fri, 21 Oct 2016 06:14:23 -0700

> On Fri, 2016-10-21 at 14:56 +0200, Jiri Kosina wrote:
>> On Fri, 21 Oct 2016, Eric Dumazet wrote:
>> 
>> > Some of us are dealing with huge HTB hierarchies, so adding default fifo
>> > in the dump will add more data pumped from the kernel.
>> > 
>> > BwE [1] for instance dumps qdisc/classes every 5 seconds.
>> > 
>> > I guess we'll need to not pull this patch in our kernels.
>> 
>> Okay, so I probably misunderstood you here:
>> 
>> 	https://marc.info/?l=linux-kernel&m=146073234818214&w=2
>> 
>> as I thought that as long as we move towards the hashtable, you wouldn't 
>> have any issues with this.
>> 
>> I'd really like to unhide the default qdiscs, it makes little sense to be 
>> inconsistent in this way.
>> 
>> Random shot into darkness -- how about making this a 
>> CONFIG/sysctl-selectable?
> 
> Oh sorry for the confusion, I believe your patch is fine.
> 
> We could add an netlink attribute later for the users that really do not
> want default fifo being dumped, but there is no hurry.

If this is changing default behavior we should approach this the other
way around.

Keep behaving the way we do, user asks for new behavior with the attribute.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ