netdev - Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

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:	Thu, 17 Mar 2016 13:56:32 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Murali Karicheri <m-karicheri2@...com>,
	David Miller <davem@...emloft.net>, sfeldma@...il.com
CC:	netdev@...r.kernel.org, andrew@...n.ch, jiri@...nulli.us
Subject: Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

On March 17, 2016 1:10:31 PM PDT, Murali Karicheri <m-karicheri2@...com> wrote:
>David,
>
>On 08/18/2015 04:47 PM, David Miller wrote:
>> I see some drivers where the foo_debugfs.c file is larger than the
>rest
>> of the driver.  Once people start using it, it's like crack, and they
>> dump every single debugging widget they found useful at some point
>into
>> there.
>> 
>> This is not what we want.  Most things I see in debugfs support was
>> probably useful for debugging one particular bug but then it was
>never
>> really useful again in the future.  Those kinds of things can be done
>> locally in someone's tree.
>> 
>> I often see various kinds of "statistics" ending up in these things,
>> or register dumps, both of which are 'ethtool' or similar material.
>Very late to this discussion, but I need to port some of the internal
>code
>to display the content of a ALE (Address Learning Engine) table
>maintained
>in hardwareat L2 layer. Currently I have a sysfs implementation that
>dumps
>information like below.
>
>root@...-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table
>index 0, raw: 000007fc d000ffff ffffffff, type: addr(1), addr:
>ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super
>index 1, raw: 00000000 10000800 28329a1c, type: addr(1), addr:
>08:00:28:32:9a:1c, uctype: persistent(0), port: 0
>index 2, raw: 000007fc d0000100 5e000001, type: addr(1), addr:
>01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super
>index 19, raw: 00000004 d000d4be d93db6c1, type: addr(1), addr:
>d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1
>
>What is the available interface in kernel to expose this information
>to user space as debugfs is not suggested based on this thread

Using something like bridge fdb show (bridge sub command part of iproute2) would give you most of what you need here, except the port mask (since that is semi implied by which interface you use for dumping) and internal flags about the address validity.

How frequently is this code used once you have a proper switch driver which supports the FDB add/del/dump operations?


-- 
Florian