netdev - Re: [PATCH bpf-next v5 0/8] xdp: Avoid unloading xdp prog not attached by sample

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: <20190201224720.3b4a1b5a@maciek-lenovo>
Date:   Fri, 1 Feb 2019 22:47:20 +0100
From:   Maciej Fijałkowski 
        <maciejromanfijalkowski@...il.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     ast@...nel.org, netdev@...r.kernel.org,
        jakub.kicinski@...ronome.com, brouer@...hat.com,
        john.fastabend@...il.com
Subject: Re: [PATCH bpf-next v5 0/8] xdp: Avoid unloading xdp prog not
 attached by sample

On Fri, 1 Feb 2019 22:23:45 +0100
Daniel Borkmann <daniel@...earbox.net> wrote:

> On 02/01/2019 01:19 AM, Maciej Fijalkowski wrote:
> > Hi!
> > This patchset tries to address the situation where:
> > * user loads a particular xdp sample application that does stats polling
> > * user loads another sample application on the same interface
> > * then, user sends SIGINT/SIGTERM to the app that was attached as a first
> > one
> > * second application ends up with an unloaded xdp program
> > 
> > 1st patch contains a helper libbpf function for getting the map fd by a
> > given map name.
> > In patch 2 Jesper removes the read_trace_pipe usage from xdp_redirect_cpu
> > which was a blocker for converting this sample to libbpf usage.
> > 3rd patch updates a bunch of xdp samples to make the use of libbpf.
> > Patch 4 adjusts RLIMIT_MEMLOCK for two samples touched in this patchset.
> > In patch 5 extack messages are added for cases where dev_change_xdp_fd
> > returns with an error so user has an idea what was the reason for not
> > attaching the xdp program onto interface.
> > Patch 6 makes the samples behavior similar to what iproute2 does when
> > loading xdp prog - the "force" flag is introduced.
> > Patch 7 introduces the libbpf function that will query the driver from
> > userspace about the currently attached xdp prog id.
> > 
> > Use it in samples that do polling by checking the prog id in signal handler
> > and comparing it with previously stored one which is the scope of patch 8.
> > 
> > Thanks!
> > 
> > v1->v2:
> > * add a libbpf helper for getting a prog via relative index
> > * include xdp_redirect_cpu into conversion
> > 
> > v2->v3: mostly addressing Daniel's/Jesper's comments
> > * get rid of the helper from v1->v2
> > * feed the xdp_redirect_cpu with program name instead of number
> > 
> > v3->v4:
> > * fix help message in xdp_sample_pkts
> > 
> > v4->v5:
> > * in get_link_xdp_fd, assign prog_id only when libbpf_nl_get_link returned
> >   with 0
> > * add extack messages in dev_change_xdp_fd
> > * check the return value of bpf_get_link_xdp_id when exiting from sample
> > progs
> 
> Series looks good to me, but doesn't apply cleanly, please rebase.
> 
> Thanks,
> Daniel

Sure, sending v6 in a minute.