linux-kernel - Re: [PATCH] net: sched: make default fifo qdiscs appear in the dump

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]

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.