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: <20230426191336.kucul56wa4p7topa@skbuf>
Date:   Wed, 26 Apr 2023 22:13:36 +0300
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Masami Hiramatsu <mhiramat@...nel.org>,
        Andrew Lunn <andrew@...n.ch>, 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>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH net-next 0/2] DSA trace events

On Mon, Apr 24, 2023 at 06:25:54PM -0400, Steven Rostedt wrote:
> On Fri, 21 Apr 2023 15:47:08 +0300
> Vladimir Oltean <vladimir.oltean@....com> wrote:
> 
> > On Fri, Apr 21, 2023 at 09:38:50PM +0900, Masami Hiramatsu wrote:
> > > If the subsystem maintainers are OK for including this, it is OK.
> > > But basically, since the event is exposed to userland and you may keep
> > > these events maintained, you should carefully add the events.
> > > If those are only for debugging (after debug, it will not be used
> > > frequently), can you consider to use kprobe events?
> > > 'perf probe' command will also help you to trace local variables and
> > > structure members as like gdb does.  
> > 
> > Thanks for taking a look. I haven't looked at kprobe events. I also
> > wasn't planning on maintaining these assuming stable UABI terms, just
> > for debugging. What are some user space consumers that expect the UABI
> > to be stable, and what is it about the trace events that can/can't change?
> 
> Ideally, tooling will use the libtraceevent library[1] to parse the
> events. In that case, if an event is used by tooling, you'll need to
> keep around the fields that are used by the tooling.

Ok, I did not plan for user space to treat these events as something
stable to pick up on. The Linux bridge already notifies VLANs, FDBs,
MDBs through the rtnetlink socket, and that's what I would consider to
be the stable ABI. What can be seen here (DSA) is essentially a
framework used by multiple hardware drivers, but ultimately still device
driver-level code.

What would you recommend here? A revert?