From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2E8F8C169C4 for ; Tue, 12 Feb 2019 00:47:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F0441217FA for ; Tue, 12 Feb 2019 00:47:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rTxyeI3m" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728010AbfBLAri (ORCPT ); Mon, 11 Feb 2019 19:47:38 -0500 Received: from mail-it1-f195.google.com ([209.85.166.195]:34998 "EHLO mail-it1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727791AbfBLAri (ORCPT ); Mon, 11 Feb 2019 19:47:38 -0500 Received: by mail-it1-f195.google.com with SMTP id v72so3233557itc.0; Mon, 11 Feb 2019 16:47:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=2eeipioDAYZkhQHxH/3kDq/lAKmWMSgQCHgc8C+jp60=; b=rTxyeI3mWq4mGX2UXBTX1AY0S5fmHZ0+/FGlvTApBDHAGFW3iHu/t9/uqiJr/1UVDM F/B5djt/Vbmjmup9N33a2MsEwcByi1uK3uEqxZnDZzeBwvEyIxXH2yjx551qdMNgzB8D 6HgidwRi8H7KtzdhP6DIS85WaYC9YHLk0cpx8mkqa8qb+EYZHAHEAxzzNgLdFTqOCd/1 4BvPIbZqwmNmVEyOkxKLuUGX1ixcZ7cz+ipxKtJGdPwxJL03IXUs26TQzFh+DHQ6dhms pT+7Os5jYvpghcWc7oFN74wGvEdaJ4YwRRDFKgeFmG4Ke+9tEn90OAg3TKFHFN1CdVg8 iv0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :mime-version:content-transfer-encoding; bh=2eeipioDAYZkhQHxH/3kDq/lAKmWMSgQCHgc8C+jp60=; b=kKPUHP/CXotMSj2Oz7Mb3T7S0OTy6Zb+PWhbXbMne4ofrJfZDi4tZ/WUfUFbOPMGv1 eFjLmCAi6RYi0Z3y2cLwTwKCHS3UAXtkhRfPRmYiEauwko7V9t3d8GQRogSedNSMKV7K Fwg+QopmR/wBVGEFEO1zAirakjuDi1geKHhFWEWGQY7J8s4ubpO225b2RKErPSAScWUJ yidA2GMjRhRz97oOCZ0JJLWEajXS+27eHF5UGjYFk3zFTFFFI4sZaH9iHZS7LPLsD+iP LJOcRMhjGh89vkML1tdvOnehZuvXGMSP2rcewfKBpsrvjdEDMQXtSkGSuCxnhakkWGdl digQ== X-Gm-Message-State: AHQUAubkG3CEo/pmuHHU1RP7xnFweipzflGWI1nzeldj5SP1vtCgOvdK T4zsIMZkAglS7U9ndNYXkVlGYvcf X-Google-Smtp-Source: AHgI3IY+Y6zxia0j+ORLrjfAHZir+kIafRDmE3B6wIsI7Y1UiHlkzngv3MCTyA6HHkGAg7BXc9EjSg== X-Received: by 2002:a24:dd0a:: with SMTP id t10mr528963itf.122.1549932457210; Mon, 11 Feb 2019 16:47:37 -0800 (PST) Received: from localhost.localdomain (mr-urb-183-235.dmisinetworks.net. [66.253.183.235]) by smtp.gmail.com with ESMTPSA id v193sm766829itv.32.2019.02.11.16.47.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Feb 2019 16:47:36 -0800 (PST) From: Joe Stringer 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 Message-Id: <20190212004729.535-1-joe@wand.net.nz> X-Mailer: git-send-email 2.19.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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