netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joe Stringer <joe@wand.net.nz>
To: bpf@vger.kernel.org
Cc: netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org
Subject: [PATCH bpf-next 0/4] libbpf: Add support for 32-bit static data
Date: Mon, 11 Feb 2019 16:47:25 -0800	[thread overview]
Message-ID: <20190212004729.535-1-joe@wand.net.nz> (raw)

This series adds support to libbpf for relocating references to 32-bit
static data inside ELF files, both for .data and .bss, similar to one of
the approaches proposed in LPC 2018[0]. This improves a common workflow
for BPF users, where the BPF program may be customised each time it is
loaded, for example to tailor IP addresses for each instance of the
loaded program. Current approaches require full recompilation of the
programs for each load, however with templatized BPF programs, one ELF
template program may be generated, then the static data can be easily
substituted prior to loading into the kernel without invoking the
compiler again.

The approach here is useful for templating limited static data for ELF
programs, and will work regardless of kernel support for static data
sections. Its main limitation is that static data must be defined as
32-bit values in the BPF C input code (or defined using macros that use
32-bit values as the underlying store). The alternative approach
proposed at LPC would be more general and is being actively explored,
however it requires kernel extension and so will not solve this problem
for any existing kernels that are in use today.

There are similar patches floating around for iproute2 which I would
like to upstream as well[1].

[0] https://linuxplumbersconf.org/event/2/contributions/115/
[1] https://github.com/joestringer/iproute2/tree/bss

Joe Stringer (4):
  libbpf: Refactor relocations
  libbpf: Support 32-bit static data loads
  libbpf: Support relocations for bss.
  selftests/bpf: Test static data relocation

 tools/lib/bpf/libbpf.c                        | 108 ++++++++++++------
 tools/testing/selftests/bpf/Makefile          |   2 +-
 tools/testing/selftests/bpf/test_progs.c      |  44 +++++++
 .../selftests/bpf/test_static_data_kern.c     |  47 ++++++++
 4 files changed, 168 insertions(+), 33 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/test_static_data_kern.c

-- 
2.19.1


             reply	other threads:[~2019-02-12  0:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-12  0:47 Joe Stringer [this message]
2019-02-12  0:47 ` [PATCH bpf-next 1/4] libbpf: Refactor relocations Joe Stringer
2019-02-12  0:47 ` [PATCH bpf-next 2/4] libbpf: Support 32-bit static data loads Joe Stringer
2019-02-15  5:38   ` Y Song
2019-02-15  7:16     ` Joe Stringer
2019-02-15 20:18       ` Y Song
2019-02-27 22:42         ` Y Song
2019-02-15 16:17     ` Alexei Starovoitov
2019-02-12  0:47 ` [PATCH bpf-next 3/4] libbpf: Support relocations for bss Joe Stringer
2019-02-12  0:47 ` [PATCH bpf-next 4/4] selftests/bpf: Test static data relocation Joe Stringer
2019-02-12  5:01   ` Alexei Starovoitov
2019-02-12 20:43     ` Joe Stringer
2019-02-14  0:35       ` Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190212004729.535-1-joe@wand.net.nz \
    --to=joe@wand.net.nz \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).