netdev - Re: [PATCH net-next 0/2] DSA trace events

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: <20230426194301.mtw2d5ooi3ywtxad@skbuf>
Date:   Wed, 26 Apr 2023 22:43:01 +0300
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Steven Rostedt <rostedt@...dmis.org>, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>
Cc:     Masami Hiramatsu <mhiramat@...nel.org>, netdev@...r.kernel.org,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net-next 0/2] DSA trace events

On Wed, Apr 26, 2023 at 03:23:45PM -0400, Steven Rostedt wrote:
> There's lots of events in the kernel that no tools use. Do you expect
> anyone to create a tool that uses these events?
> 
> We break user space API all the time. As long as nothing notices, it's OK.
> We take the "tree in the forest" approach. If user space API breaks, but no
> tool uses it, did it break? The answer according to Linus, is "no".
> 
> Al Viro refuses to have trace events in VFS, because there's lots of places
> that could become useful for tooling, and he doesn't want to support it.
> But if the events are not useful for user space tooling, they should be
> generally safe to keep.
> 
> There's tons of events in the wifi code, because they are very useful for
> debugging remote applications out in the world, that the wifi maintainers
> have tooling for. But those are not considered "stable", because the only
> tools are the ones that the maintainer of the trace events, created.
> 
> If you don't see anything using these events for useful tooling outside
> your own use, then I'd just keep them. There's a thousand other events in
> the kernel that are not used by tools, I doubt these will be any different.
> 
> If you think that a tool that will end up in a distribution will start
> using them, then you need to take care.

Well, there's one thing that could become useful for tooling, and
that's determining the resource utilization of the hardware (number of
dsa_fdb_add_hw events minus dsa_fdb_del_hw, number of dsa_vlan_add_hw
minus dsa_vlan_del_hw, etc) relative to some hardcoded maximum capacity
which would be somehow determined by userspace for each driver. There
have been requests for this in the not so distant past.

Instead of living in fear that this might happen, I think what would be
the most productive thing to do would be to just create a proper API in
the next kernel development cycle to expose just that information, and
point other people to that other API, and keep the trace events just for
debugging.

Andrew, Florian, what do you think?