netdev - Re: [patch net-next v2 11/11] devlink: extend health reporter dump selector by port index

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, 1 Aug 2023 08:49:45 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, pabeni@...hat.com, davem@...emloft.net,
	edumazet@...gle.com, moshe@...dia.com, saeedm@...dia.com,
	idosch@...dia.com, petrm@...dia.com
Subject: Re: [patch net-next v2 11/11] devlink: extend health reporter dump
 selector by port index

Mon, Jul 31, 2023 at 07:06:32PM CEST, kuba@...nel.org wrote:
>On Mon, 31 Jul 2023 14:52:44 +0200 Jiri Pirko wrote:
>> >This patch is not very clean. IMHO implementing the filters by skipping
>> >is not going to scale to reasonably complex filters. Isn't it better to  
>> 
>> I'm not sure what do you mean by skipping? There is not skipping. In
>> case PORT_INDEX is passed in the selector, only that specific port is
>> processed. No scale issues I see. Am I missing something?
>> 
>> 
>> >add a .filter callback which will look at the about-to-be-dumped object
>> >and return true/false on whether it should be dumped?  
>> 
>> No, that would not scale. Passing the selector attrs to the dump
>> callback it better, as the dump callback according to the attrs can
>> reach only what is needed, knowing the internals. But perhaps I don't
>> understand correctly your suggestion.
>
>for_each_obj() {
>	if (obj_dump_filtered(obj, dump_info))  // < run filter
>		continue;                       // < skip object
>
>	dump_one(obj)

I don't see how this would help. For example, passing PORT_INDEX, I know
exactly what object to reach, according to this PORT_INDEX. Why to
iterate over all of them and try the filter? Does not make sense to me.

Maybe we are each understanding this feature differently. This is about
passing keys which index the objects. It is always devlink handle,
sometimes port index and I see another example in shared buffer index.
That's about it. Basically user passes partial tuple of indexes.
Example:
devlink port show
the key is: bus_name/dev_name/port_index
user passes bus_name/dev_name, this is the selector, a partial key.

The sophisticated filtering is not a focus of this patchset. User can do
it putting bpf filter on the netlink socket.