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: <20191217005944.s3mayy473ldlnldl@ast-mbp.dhcp.thefacebook.com>
Date:   Mon, 16 Dec 2019 16:59:45 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Björn Töpel <bjorn.topel@...il.com>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Netdev <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Ido Schimmel <idosch@...sch.org>
Subject: Re: [RFC PATCH bpf-next] xdp: Add tracepoint on XDP program return

On Mon, Dec 16, 2019 at 07:17:59PM +0100, Björn Töpel wrote:
> On Mon, 16 Dec 2019 at 16:28, Toke Høiland-Jørgensen <toke@...hat.com> wrote:
> >
> > This adds a new tracepoint, xdp_prog_return, which is triggered at every
> > XDP program return. This was first discussed back in August[0] as a way to
> > hook XDP into the kernel drop_monitor framework, to have a one-stop place
> > to find all packet drops in the system.
> >
> > Because trace/events/xdp.h includes filter.h, some ifdef guarding is needed
> > to be able to use the tracepoint from bpf_prog_run_xdp(). If anyone has any
> > ideas for how to improve on this, please to speak up. Sending this RFC
> > because of this issue, and to get some feedback from Ido on whether this
> > tracepoint has enough data for drop_monitor usage.
> >
> 
> I get that it would be useful, but can it be solved with BPF tracing
> (i.e. tracing BPF with BPF)? It would be neat not adding another
> tracepoint in the fast-path...

That was my question as well.
Here is an example from Eelco:
https://lore.kernel.org/bpf/78D7857B-82E4-42BC-85E1-E3D7C97BF840@redhat.com/
BPF_TRACE_2("fexit/xdp_prog_simple", trace_on_exit,
             struct xdp_buff*, xdp, int, ret)
{
     bpf_debug("fexit: [ifindex = %u, queue =  %u, ret = %d]\n",
               xdp->rxq->dev->ifindex, xdp->rxq->queue_index, ret);

     return 0;
}
'ret' is return code from xdp program.
Such approach is per xdp program, but cheaper when not enabled
and faster when it's triggering comparing to static tracepoint.
Anything missing there that you'd like to see?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ