netdev - Re: [PATCH] net: tracepoint: exposing sk

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: <YBrOnJvBGKi0aa7G@google.com>
Date:   Wed, 3 Feb 2021 08:26:04 -0800
From:   sdf@...gle.com
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Hariharan Ananthakrishnan <hari@...flix.com>,
        "David S . Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Song Liu <songliubraving@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Brendan Gregg <bgregg@...flix.com>
Subject: Re: [PATCH] net: tracepoint: exposing sk_family in all tcp:tracepoints

On 02/02, Eric Dumazet wrote:
> On Mon, Feb 1, 2021 at 11:06 PM Jakub Kicinski <kuba@...nel.org> wrote:
> >
> > On Fri, 29 Jan 2021 00:12:10 +0000 Hariharan Ananthakrishnan wrote:
> > > Similar to sock:inet_sock_set_state tracepoint, expose sk_family to
> > > distinguish AF_INET and AF_INET6 families.
> > >
> > > The following tcp tracepoints are updated:
> > > tcp:tcp_destroy_sock
> > > tcp:tcp_rcv_space_adjust
> > > tcp:tcp_retransmit_skb
> > > tcp:tcp_send_reset
> > > tcp:tcp_receive_reset
> > > tcp:tcp_retransmit_synack
> > > tcp:tcp_probe
> > >
> > > Signed-off-by: Hariharan Ananthakrishnan <hari@...flix.com>
> > > Signed-off-by: Brendan Gregg <bgregg@...flix.com>
> >
> > Eric, any thoughts?


> I do not use these tracepoints in production scripts, but I wonder if
> existing tools could break after this change ?

> Or do we consider tracepoints format is not part of the ABI and can be
> arbitrarily changed by anyone ?
They are not ABI and since we are extending tracepoints with additional
info (and not removing any existing fields) it shouldn't be a problem.