Merge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next

The BTF_ID macro does not cause a function to become part of the ABI

any more than does the EXPORT_SYMBOL_GPL macro.

Q: What is the compatibility story for special BPF types in map values?

-----------------------------------------------------------------------

Q: Users are allowed to embed bpf_spin_lock, bpf_timer fields in their BPF map

values (when using BTF support for BPF maps). This allows to use helpers for

such objects on these fields inside map values. Users are also allowed to embed

pointers to some kernel types (with __kptr and __kptr_ref BTF tags). Will the

kernel preserve backwards compatibility for these features?

A: It depends. For bpf_spin_lock, bpf_timer: YES, for kptr and everything else:

NO, but see below.

For struct types that have been added already, like bpf_spin_lock and bpf_timer,

the kernel will preserve backwards compatibility, as they are part of UAPI.

For kptrs, they are also part of UAPI, but only with respect to the kptr

mechanism. The types that you can use with a __kptr and __kptr_ref tagged

pointer in your struct are NOT part of the UAPI contract. The supported types can

and will change across kernel releases. However, operations like accessing kptr

fields and bpf_kptr_xchg() helper will continue to be supported across kernel

releases for the supported types.

For any other supported struct type, unless explicitly stated in this document

and added to bpf.h UAPI header, such types can and will arbitrarily change their

size, type, and alignment, or any other user visible API or ABI detail across

kernel releases. The users must adapt their BPF programs to the new changes and

update them to make sure their programs continue to work correctly.

NOTE: BPF subsystem specially reserves the 'bpf\_' prefix for type names, in

order to introduce more special fields in the future. Hence, user programs must

avoid defining types with 'bpf\_' prefix to not be broken in future releases.

In other words, no backwards compatibility is guaranteed if one using a type

in BTF with 'bpf\_' prefix.

Q: What is the compatibility story for special BPF types in local kptrs?

------------------------------------------------------------------------

Q: Same as above, but for local kptrs (i.e. pointers to objects allocated using

bpf_obj_new for user defined structures). Will the kernel preserve backwards

compatibility for these features?

A: NO.

Unlike map value types, there are no stability guarantees for this case. The

whole local kptr API itself is unstable (since it is exposed through kfuncs).

.. SPDX-License-Identifier: GPL-2.0-only

.. Copyright (C) 2022 Red Hat, Inc.

================================================

BPF_MAP_TYPE_ARRAY and BPF_MAP_TYPE_PERCPU_ARRAY

================================================

.. note::

   - ``BPF_MAP_TYPE_ARRAY`` was introduced in kernel version 3.19

   - ``BPF_MAP_TYPE_PERCPU_ARRAY`` was introduced in version 4.6

``BPF_MAP_TYPE_ARRAY`` and ``BPF_MAP_TYPE_PERCPU_ARRAY`` provide generic array

storage. The key type is an unsigned 32-bit integer (4 bytes) and the map is

of constant size. The size of the array is defined in ``max_entries`` at

creation time. All array elements are pre-allocated and zero initialized when

created. ``BPF_MAP_TYPE_PERCPU_ARRAY`` uses a different memory region for each

CPU whereas ``BPF_MAP_TYPE_ARRAY`` uses the same memory region. The value

stored can be of any size, however, all array elements are aligned to 8

bytes.

Since kernel 5.5, memory mapping may be enabled for ``BPF_MAP_TYPE_ARRAY`` by

setting the flag ``BPF_F_MMAPABLE``. The map definition is page-aligned and

starts on the first page. Sufficient page-sized and page-aligned blocks of

memory are allocated to store all array values, starting on the second page,

which in some cases will result in over-allocation of memory. The benefit of

using this is increased performance and ease of use since userspace programs

would not be required to use helper functions to access and mutate data.

Usage

=====

Kernel BPF

----------

.. c:function::

   void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)

Array elements can be retrieved using the ``bpf_map_lookup_elem()`` helper.

This helper returns a pointer into the array element, so to avoid data races

with userspace reading the value, the user must use primitives like

``__sync_fetch_and_add()`` when updating the value in-place.

.. c:function::

   long bpf_map_update_elem(struct bpf_map *map, const void *key, const void *value, u64 flags)

Array elements can be updated using the ``bpf_map_update_elem()`` helper.

``bpf_map_update_elem()`` returns 0 on success, or negative error in case of

failure.

Since the array is of constant size, ``bpf_map_delete_elem()`` is not supported.

To clear an array element, you may use ``bpf_map_update_elem()`` to insert a

zero value to that index.

Per CPU Array

~~~~~~~~~~~~~

Values stored in ``BPF_MAP_TYPE_ARRAY`` can be accessed by multiple programs

across different CPUs. To restrict storage to a single CPU, you may use a

``BPF_MAP_TYPE_PERCPU_ARRAY``.

When using a ``BPF_MAP_TYPE_PERCPU_ARRAY`` the ``bpf_map_update_elem()`` and

``bpf_map_lookup_elem()`` helpers automatically access the slot for the current

CPU.

.. c:function::

   void *bpf_map_lookup_percpu_elem(struct bpf_map *map, const void *key, u32 cpu)

The ``bpf_map_lookup_percpu_elem()`` helper can be used to lookup the array

value for a specific CPU. Returns value on success , or ``NULL`` if no entry was

found or ``cpu`` is invalid.

Concurrency

-----------

Since kernel version 5.1, the BPF infrastructure provides ``struct bpf_spin_lock``

to synchronize access.

Userspace

---------

Access from userspace uses libbpf APIs with the same names as above, with

the map identified by its ``fd``.

Examples

========

Please see the ``tools/testing/selftests/bpf`` directory for functional

examples. The code samples below demonstrate API usage.

Kernel BPF

----------

This snippet shows how to declare an array in a BPF program.

.. code-block:: c

    struct {

            __uint(type, BPF_MAP_TYPE_ARRAY);

            __type(key, u32);

            __type(value, long);

            __uint(max_entries, 256);

    } my_map SEC(".maps");

This example BPF program shows how to access an array element.

.. code-block:: c

    int bpf_prog(struct __sk_buff *skb)

    {

            struct iphdr ip;

            int index;

            long *value;

            if (bpf_skb_load_bytes(skb, ETH_HLEN, &ip, sizeof(ip)) < 0)

                    return 0;

            index = ip.protocol;

            value = bpf_map_lookup_elem(&my_map, &index);

            if (value)

                    __sync_fetch_and_add(&value, skb->len);

            return 0;

    }

Userspace

---------

BPF_MAP_TYPE_ARRAY

~~~~~~~~~~~~~~~~~~

This snippet shows how to create an array, using ``bpf_map_create_opts`` to

set flags.

.. code-block:: c

    #include <bpf/libbpf.h>

    #include <bpf/bpf.h>

    int create_array()

    {

            int fd;

            LIBBPF_OPTS(bpf_map_create_opts, opts, .map_flags = BPF_F_MMAPABLE);

            fd = bpf_map_create(BPF_MAP_TYPE_ARRAY,

                                "example_array",       /* name */

                                sizeof(__u32),         /* key size */

                                sizeof(long),          /* value size */

                                256,                   /* max entries */

                                &opts);                /* create opts */

            return fd;

    }

This snippet shows how to initialize the elements of an array.

.. code-block:: c

    int initialize_array(int fd)

    {

            __u32 i;

            long value;

            int ret;

            for (i = 0; i < 256; i++) {

                    value = i;

                    ret = bpf_map_update_elem(fd, &i, &value, BPF_ANY);

                    if (ret < 0)

                            return ret;

            }

            return ret;

    }

This snippet shows how to retrieve an element value from an array.

.. code-block:: c

    int lookup(int fd)

    {

            __u32 index = 42;

            long value;

            int ret;

            ret = bpf_map_lookup_elem(fd, &index, &value);

            if (ret < 0)

                    return ret;

            /* use value here */

            assert(value == 42);

            return ret;

    }

BPF_MAP_TYPE_PERCPU_ARRAY

~~~~~~~~~~~~~~~~~~~~~~~~~

This snippet shows how to initialize the elements of a per CPU array.

.. code-block:: c

    int initialize_array(int fd)

    {

            int ncpus = libbpf_num_possible_cpus();

            long values[ncpus];

            __u32 i, j;

            int ret;

            for (i = 0; i < 256 ; i++) {

                    for (j = 0; j < ncpus; j++)

                            values[j] = i;

                    ret = bpf_map_update_elem(fd, &i, &values, BPF_ANY);

                    if (ret < 0)

                            return ret;

            }

            return ret;

    }

This snippet shows how to access the per CPU elements of an array value.

.. code-block:: c

    int lookup(int fd)

    {

            int ncpus = libbpf_num_possible_cpus();

            __u32 index = 42, j;

            long values[ncpus];

            int ret;

            ret = bpf_map_lookup_elem(fd, &index, &values);

            if (ret < 0)

                    return ret;

            for (j = 0; j < ncpus; j++) {

                    /* Use per CPU value here */

                    assert(values[j] == 42);

            }

            return ret;

    }

Semantics

=========

As shown in the example above, when accessing a ``BPF_MAP_TYPE_PERCPU_ARRAY``

in userspace, each value is an array with ``ncpus`` elements.

When calling ``bpf_map_update_elem()`` the flag ``BPF_NOEXIST`` can not be used

for these maps.

.. SPDX-License-Identifier: GPL-2.0-only

.. Copyright (C) 2022 Red Hat, Inc.

===================

BPF_MAP_TYPE_CPUMAP

===================

.. note::

   - ``BPF_MAP_TYPE_CPUMAP`` was introduced in kernel version 4.15

.. kernel-doc:: kernel/bpf/cpumap.c

 :doc: cpu map

An example use-case for this map type is software based Receive Side Scaling (RSS).

The CPUMAP represents the CPUs in the system indexed as the map-key, and the

map-value is the config setting (per CPUMAP entry). Each CPUMAP entry has a dedicated

kernel thread bound to the given CPU to represent the remote CPU execution unit.

Starting from Linux kernel version 5.9 the CPUMAP can run a second XDP program

on the remote CPU. This allows an XDP program to split its processing across

multiple CPUs. For example, a scenario where the initial CPU (that sees/receives

the packets) needs to do minimal packet processing and the remote CPU (to which

the packet is directed) can afford to spend more cycles processing the frame. The

initial CPU is where the XDP redirect program is executed. The remote CPU

receives raw ``xdp_frame`` objects.

Usage

=====

Kernel BPF

----------

.. c:function::

     long bpf_redirect_map(struct bpf_map *map, u32 key, u64 flags)

 Redirect the packet to the endpoint referenced by ``map`` at index ``key``.

 For ``BPF_MAP_TYPE_CPUMAP`` this map contains references to CPUs.

 The lower two bits of ``flags`` are used as the return code if the map lookup

 fails. This is so that the return value can be one of the XDP program return

 codes up to ``XDP_TX``, as chosen by the caller.

Userspace

---------

.. note::

    CPUMAP entries can only be updated/looked up/deleted from user space and not

    from an eBPF program. Trying to call these functions from a kernel eBPF

    program will result in the program failing to load and a verifier warning.

.. c:function::

    int bpf_map_update_elem(int fd, const void *key, const void *value,

                   __u64 flags);

 CPU entries can be added or updated using the ``bpf_map_update_elem()``

 helper. This helper replaces existing elements atomically. The ``value`` parameter

 can be ``struct bpf_cpumap_val``.

 .. code-block:: c

    struct bpf_cpumap_val {

        __u32 qsize;  /* queue size to remote target CPU */

        union {

            int   fd; /* prog fd on map write */

            __u32 id; /* prog id on map read */

        } bpf_prog;

    };

 The flags argument can be one of the following:

  - BPF_ANY: Create a new element or update an existing element.

  - BPF_NOEXIST: Create a new element only if it did not exist.

  - BPF_EXIST: Update an existing element.

.. c:function::

    int bpf_map_lookup_elem(int fd, const void *key, void *value);

 CPU entries can be retrieved using the ``bpf_map_lookup_elem()``

 helper.

.. c:function::

    int bpf_map_delete_elem(int fd, const void *key);

 CPU entries can be deleted using the ``bpf_map_delete_elem()``

 helper. This helper will return 0 on success, or negative error in case of

 failure.

Examples

========

Kernel

------

The following code snippet shows how to declare a ``BPF_MAP_TYPE_CPUMAP`` called

``cpu_map`` and how to redirect packets to a remote CPU using a round robin scheme.

.. code-block:: c

   struct {

        __uint(type, BPF_MAP_TYPE_CPUMAP);

        __type(key, __u32);

        __type(value, struct bpf_cpumap_val);

        __uint(max_entries, 12);

    } cpu_map SEC(".maps");

    struct {

        __uint(type, BPF_MAP_TYPE_ARRAY);

        __type(key, __u32);

        __type(value, __u32);

        __uint(max_entries, 12);

    } cpus_available SEC(".maps");

    struct {

        __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);

        __type(key, __u32);

        __type(value, __u32);

        __uint(max_entries, 1);

    } cpus_iterator SEC(".maps");

    SEC("xdp")

    int  xdp_redir_cpu_round_robin(struct xdp_md *ctx)

    {

        __u32 key = 0;

        __u32 cpu_dest = 0;

        __u32 *cpu_selected, *cpu_iterator;

        __u32 cpu_idx;

        cpu_iterator = bpf_map_lookup_elem(&cpus_iterator, &key);

        if (!cpu_iterator)

            return XDP_ABORTED;

        cpu_idx = *cpu_iterator;

        *cpu_iterator += 1;

        if (*cpu_iterator == bpf_num_possible_cpus())

            *cpu_iterator = 0;

        cpu_selected = bpf_map_lookup_elem(&cpus_available, &cpu_idx);

        if (!cpu_selected)

            return XDP_ABORTED;

        cpu_dest = *cpu_selected;

        if (cpu_dest >= bpf_num_possible_cpus())

            return XDP_ABORTED;

        return bpf_redirect_map(&cpu_map, cpu_dest, 0);

    }

Userspace

---------

The following code snippet shows how to dynamically set the max_entries for a

CPUMAP to the max number of cpus available on the system.

.. code-block:: c

    int set_max_cpu_entries(struct bpf_map *cpu_map)

    {

        if (bpf_map__set_max_entries(cpu_map, libbpf_num_possible_cpus()) < 0) {

            fprintf(stderr, "Failed to set max entries for cpu_map map: %s",

                strerror(errno));

            return -1;

        }

        return 0;

    }

References

===========

- https://developers.redhat.com/blog/2021/05/13/receive-side-scaling-rss-with-ebpf-and-cpumap#redirecting_into_a_cpumap

.. SPDX-License-Identifier: GPL-2.0-only

.. Copyright (C) 2022 Red Hat, Inc.

=====================

BPF_MAP_TYPE_LPM_TRIE

=====================

.. note::

   - ``BPF_MAP_TYPE_LPM_TRIE`` was introduced in kernel version 4.11

``BPF_MAP_TYPE_LPM_TRIE`` provides a longest prefix match algorithm that

can be used to match IP addresses to a stored set of prefixes.

Internally, data is stored in an unbalanced trie of nodes that uses

``prefixlen,data`` pairs as its keys. The ``data`` is interpreted in

network byte order, i.e. big endian, so ``data[0]`` stores the most

significant byte.

LPM tries may be created with a maximum prefix length that is a multiple

of 8, in the range from 8 to 2048. The key used for lookup and update

operations is a ``struct bpf_lpm_trie_key``, extended by

``max_prefixlen/8`` bytes.

- For IPv4 addresses the data length is 4 bytes

- For IPv6 addresses the data length is 16 bytes

The value type stored in the LPM trie can be any user defined type.

.. note::

   When creating a map of type ``BPF_MAP_TYPE_LPM_TRIE`` you must set the

   ``BPF_F_NO_PREALLOC`` flag.

Usage

=====

Kernel BPF

----------

.. c:function::

   void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)

The longest prefix entry for a given data value can be found using the

``bpf_map_lookup_elem()`` helper. This helper returns a pointer to the

value associated with the longest matching ``key``, or ``NULL`` if no

entry was found.

The ``key`` should have ``prefixlen`` set to ``max_prefixlen`` when

performing longest prefix lookups. For example, when searching for the

longest prefix match for an IPv4 address, ``prefixlen`` should be set to

``32``.

.. c:function::

   long bpf_map_update_elem(struct bpf_map *map, const void *key, const void *value, u64 flags)

Prefix entries can be added or updated using the ``bpf_map_update_elem()``

helper. This helper replaces existing elements atomically.

``bpf_map_update_elem()`` returns ``0`` on success, or negative error in

case of failure.

 .. note::

    The flags parameter must be one of BPF_ANY, BPF_NOEXIST or BPF_EXIST,

    but the value is ignored, giving BPF_ANY semantics.

.. c:function::

   long bpf_map_delete_elem(struct bpf_map *map, const void *key)

Prefix entries can be deleted using the ``bpf_map_delete_elem()``

helper. This helper will return 0 on success, or negative error in case

of failure.

Userspace

---------

Access from userspace uses libbpf APIs with the same names as above, with

the map identified by ``fd``.

.. c:function::

   int bpf_map_get_next_key (int fd, const void *cur_key, void *next_key)

A userspace program can iterate through the entries in an LPM trie using

libbpf's ``bpf_map_get_next_key()`` function. The first key can be

fetched by calling ``bpf_map_get_next_key()`` with ``cur_key`` set to

``NULL``. Subsequent calls will fetch the next key that follows the

current key. ``bpf_map_get_next_key()`` returns ``0`` on success,

``-ENOENT`` if ``cur_key`` is the last key in the trie, or negative

error in case of failure.

``bpf_map_get_next_key()`` will iterate through the LPM trie elements

from leftmost leaf first. This means that iteration will return more

specific keys before less specific ones.

Examples

========

Please see ``tools/testing/selftests/bpf/test_lpm_map.c`` for examples

of LPM trie usage from userspace. The code snippets below demonstrate

API usage.

Kernel BPF

----------

The following BPF code snippet shows how to declare a new LPM trie for IPv4

address prefixes:

.. code-block:: c

    #include <linux/bpf.h>

    #include <bpf/bpf_helpers.h>

    struct ipv4_lpm_key {

            __u32 prefixlen;

            __u32 data;

    };

    struct {

            __uint(type, BPF_MAP_TYPE_LPM_TRIE);

            __type(key, struct ipv4_lpm_key);

            __type(value, __u32);

            __uint(map_flags, BPF_F_NO_PREALLOC);

            __uint(max_entries, 255);

    } ipv4_lpm_map SEC(".maps");

The following BPF code snippet shows how to lookup by IPv4 address:

.. code-block:: c

    void *lookup(__u32 ipaddr)

    {

            struct ipv4_lpm_key key = {

                    .prefixlen = 32,

                    .data = ipaddr

            };

            return bpf_map_lookup_elem(&ipv4_lpm_map, &key);

    }

Userspace

---------

The following snippet shows how to insert an IPv4 prefix entry into an

LPM trie:

.. code-block:: c

    int add_prefix_entry(int lpm_fd, __u32 addr, __u32 prefixlen, struct value *value)

    {

            struct ipv4_lpm_key ipv4_key = {

                    .prefixlen = prefixlen,

                    .data = addr

            };

            return bpf_map_update_elem(lpm_fd, &ipv4_key, value, BPF_ANY);

    }

The following snippet shows a userspace program walking through the entries

of an LPM trie:

.. code-block:: c

    #include <bpf/libbpf.h>

    #include <bpf/bpf.h>

    void iterate_lpm_trie(int map_fd)

    {

            struct ipv4_lpm_key *cur_key = NULL;

            struct ipv4_lpm_key next_key;

            struct value value;

            int err;

            for (;;) {

                    err = bpf_map_get_next_key(map_fd, cur_key, &next_key);

                    if (err)

                            break;

                    bpf_map_lookup_elem(map_fd, &next_key, &value);

                    /* Use key and value here */

                    cur_key = &next_key;

            }

    }

.. SPDX-License-Identifier: GPL-2.0-only

.. Copyright (C) 2022 Red Hat, Inc.

========================================================

BPF_MAP_TYPE_ARRAY_OF_MAPS and BPF_MAP_TYPE_HASH_OF_MAPS

========================================================

.. note::

   - ``BPF_MAP_TYPE_ARRAY_OF_MAPS`` and ``BPF_MAP_TYPE_HASH_OF_MAPS`` were

     introduced in kernel version 4.12

``BPF_MAP_TYPE_ARRAY_OF_MAPS`` and ``BPF_MAP_TYPE_HASH_OF_MAPS`` provide general

purpose support for map in map storage. One level of nesting is supported, where

an outer map contains instances of a single type of inner map, for example

``array_of_maps->sock_map``.

When creating an outer map, an inner map instance is used to initialize the

metadata that the outer map holds about its inner maps. This inner map has a

separate lifetime from the outer map and can be deleted after the outer map has

been created.

The outer map supports element lookup, update and delete from user space using

the syscall API. A BPF program is only allowed to do element lookup in the outer

map.

.. note::

   - Multi-level nesting is not supported.

   - Any BPF map type can be used as an inner map, except for

     ``BPF_MAP_TYPE_PROG_ARRAY``.

   - A BPF program cannot update or delete outer map entries.

For ``BPF_MAP_TYPE_ARRAY_OF_MAPS`` the key is an unsigned 32-bit integer index

into the array. The array is a fixed size with ``max_entries`` elements that are

zero initialized when created.

For ``BPF_MAP_TYPE_HASH_OF_MAPS`` the key type can be chosen when defining the

map. The kernel is responsible for allocating and freeing key/value pairs, up to

the max_entries limit that you specify. Hash maps use pre-allocation of hash

table elements by default. The ``BPF_F_NO_PREALLOC`` flag can be used to disable

pre-allocation when it is too memory expensive.

Usage

=====

Kernel BPF Helper

-----------------

.. c:function::

   void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)

Inner maps can be retrieved using the ``bpf_map_lookup_elem()`` helper. This

helper returns a pointer to the inner map, or ``NULL`` if no entry was found.

Examples

========

Kernel BPF Example

------------------

This snippet shows how to create and initialise an array of devmaps in a BPF

program. Note that the outer array can only be modified from user space using

the syscall API.

.. code-block:: c

    struct inner_map {

            __uint(type, BPF_MAP_TYPE_DEVMAP);

            __uint(max_entries, 10);

            __type(key, __u32);

            __type(value, __u32);

    } inner_map1 SEC(".maps"), inner_map2 SEC(".maps");

    struct {

            __uint(type, BPF_MAP_TYPE_ARRAY_OF_MAPS);

            __uint(max_entries, 2);

            __type(key, __u32);

            __array(values, struct inner_map);

    } outer_map SEC(".maps") = {

            .values = { &inner_map1,

                        &inner_map2 }

    };

See ``progs/test_btf_map_in_map.c`` in ``tools/testing/selftests/bpf`` for more

examples of declarative initialisation of outer maps.

User Space

----------

This snippet shows how to create an array based outer map:

.. code-block:: c

    int create_outer_array(int inner_fd) {

            LIBBPF_OPTS(bpf_map_create_opts, opts, .inner_map_fd = inner_fd);

            int fd;

            fd = bpf_map_create(BPF_MAP_TYPE_ARRAY_OF_MAPS,

                                "example_array",       /* name */

                                sizeof(__u32),         /* key size */

                                sizeof(__u32),         /* value size */

                                256,                   /* max entries */

                                &opts);                /* create opts */

            return fd;

    }

This snippet shows how to add an inner map to an outer map:

.. code-block:: c

    int add_devmap(int outer_fd, int index, const char *name) {

            int fd;

            fd = bpf_map_create(BPF_MAP_TYPE_DEVMAP, name,

                                sizeof(__u32), sizeof(__u32), 256, NULL);

            if (fd < 0)

                    return fd;

            return bpf_map_update_elem(outer_fd, &index, &fd, BPF_ANY);

    }

References

==========

- https://lore.kernel.org/netdev/20170322170035.923581-3-kafai@fb.com/

- https://lore.kernel.org/netdev/20170322170035.923581-4-kafai@fb.com/