netdev - Re: [PATCH RFC v2 net-next 02/25] net/ipv6: Refactor address dump to push inet6_fill_args to in6_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:   Tue, 2 Oct 2018 18:24:03 +0200
From:   Jiri Benc <jbenc@...hat.com>
To:     David Ahern <dsahern@...il.com>
Cc:     David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org,
        davem@...emloft.net, christian@...uner.io,
        stephen@...workplumber.org
Subject: Re: [PATCH RFC v2 net-next 02/25] net/ipv6: Refactor address dump
 to push inet6_fill_args to in6_dump_addrs

On Tue, 2 Oct 2018 09:11:17 -0600, David Ahern wrote:
> Generically speaking a filter modifies the output based on the input.
> Specifying a target namespace is an input to the dump that modifies the
> output.

That's conventionally called "algorithm" :-)

Let's just say we have a different understanding of what "filter" is.
Perhaps we should look at it from a different side. What is the use
case of having NLM_F_DUMP_FILTERED set for IFA_TARGET_NETNSID? How is
this going to be used by applications?

> Yes, you can do it in userspace which is what iproute2 has done to this
> point, but it is grossly inefficient and that inefficiency has
> implications at scale.

You can't do that with IFA_TARGET_NETNSID. Which is my point. Without
the flag, you don't get a list of all interfaces in all net name spaces.

 Jiri