netdev - Re: [PATCH net-next] ipmr: ip6mr: Add ability to display non default caches and vifs

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: <e7a1828a-d5bf-fa88-1798-1d77f9875189@nvidia.com>
Date:   Thu, 19 Aug 2021 02:12:19 +0300
From:   Nikolay Aleksandrov <nikolay@...dia.com>
To:     Stephen Suryaputra <ssuryaextr@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next] ipmr: ip6mr: Add ability to display non default
 caches and vifs

On 19/08/2021 01:50, Stephen Suryaputra wrote:
> On Thu, Aug 19, 2021 at 01:37:21AM +0300, Nikolay Aleksandrov wrote:
>>
>> Sorry, but I don't see any point to this. We don't have it for any of the other
>> non-default cases, and I don't see a point of having it for ipmr either.
>> If you'd like to display the non-default tables then you query for them, you
>> don't change a sysctl to see them in /proc.
>> It sounds like a workaround for an issue that is not solved properly, and
>> generally it shouldn't be using /proc. If netlink interfaces are not sufficient
>> please improve them.
> 
> We found that the ability to dump the tables from kernel point of view
> is valuable for debugging the applications. Sometimes during the
> development, bugs in the use of the netlink interfaces can be solved
> quickly if the tables in the kernel can be viewed easily.

What does that mean, are there bugs in netlink dumping capabilities?
If so, fix those. You can already dump all kernel tables via netlink, if there's
something missing just add it.

>>
>> Why do we need a whole new sysctl or net proc entries ?
> 
> If you agree on the reasoning above, what do you recommend then? Again,
> this is to easily view what's in the kernel.
> 

I do not. You can already use netlink to dump any table, I don't see any point
in making those available via /proc, it's not a precedent. We have a ton of other
(almost any) information already exported via netlink without any need for /proc,
there really is no argument to add this new support.

> Thanks,
> Stephen.
>