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]

Date:   Fri, 1 Feb 2019 22:23:45 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Maciej Fijalkowski <maciejromanfijalkowski@...il.com>,
        ast@...nel.org
Cc:     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 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