2019-05-29 01:10:09 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2016-02-18 11:58:58 +08:00
|
|
|
/* Copyright (c) 2016 Facebook
|
|
|
|
|
*/
|
|
|
|
|
#include <linux/bpf.h>
|
|
|
|
|
#include <linux/jhash.h>
|
|
|
|
|
#include <linux/filter.h>
|
2020-07-24 02:06:44 +08:00
|
|
|
#include <linux/kernel.h>
|
2016-02-18 11:58:58 +08:00
|
|
|
#include <linux/stacktrace.h>
|
|
|
|
|
#include <linux/perf_event.h>
|
2020-07-12 05:53:24 +08:00
|
|
|
#include <linux/btf_ids.h>
|
2021-01-14 21:40:42 +08:00
|
|
|
#include <linux/buildid.h>
|
2016-03-08 13:57:17 +08:00
|
|
|
#include "percpu_freelist.h"
|
2021-11-06 07:23:29 +08:00
|
|
|
#include "mmap_unlock_work.h"
|
2016-02-18 11:58:58 +08:00
|
|
|
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
#define STACK_CREATE_FLAG_MASK \
|
|
|
|
|
(BPF_F_NUMA_NODE | BPF_F_RDONLY | BPF_F_WRONLY | \
|
|
|
|
|
BPF_F_STACK_BUILD_ID)
|
2017-10-19 04:00:22 +08:00
|
|
|
|
2016-02-18 11:58:58 +08:00
|
|
|
struct stack_map_bucket {
|
2016-03-08 13:57:17 +08:00
|
|
|
struct pcpu_freelist_node fnode;
|
2016-02-18 11:58:58 +08:00
|
|
|
u32 hash;
|
|
|
|
|
u32 nr;
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
u64 data[];
|
2016-02-18 11:58:58 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct bpf_stack_map {
|
|
|
|
|
struct bpf_map map;
|
2016-03-08 13:57:17 +08:00
|
|
|
void *elems;
|
|
|
|
|
struct pcpu_freelist freelist;
|
2016-02-18 11:58:58 +08:00
|
|
|
u32 n_buckets;
|
2023-10-07 04:17:00 +08:00
|
|
|
struct stack_map_bucket *buckets[] __counted_by(n_buckets);
|
2016-02-18 11:58:58 +08:00
|
|
|
};
|
|
|
|
|
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
static inline bool stack_map_use_build_id(struct bpf_map *map)
|
|
|
|
|
{
|
|
|
|
|
return (map->map_flags & BPF_F_STACK_BUILD_ID);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int stack_map_data_size(struct bpf_map *map)
|
|
|
|
|
{
|
|
|
|
|
return stack_map_use_build_id(map) ?
|
|
|
|
|
sizeof(struct bpf_stack_build_id) : sizeof(u64);
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-08 13:57:17 +08:00
|
|
|
static int prealloc_elems_and_freelist(struct bpf_stack_map *smap)
|
|
|
|
|
{
|
2021-09-30 21:55:45 +08:00
|
|
|
u64 elem_size = sizeof(struct stack_map_bucket) +
|
|
|
|
|
(u64)smap->map.value_size;
|
2016-03-08 13:57:17 +08:00
|
|
|
int err;
|
|
|
|
|
|
2017-08-19 02:28:00 +08:00
|
|
|
smap->elems = bpf_map_area_alloc(elem_size * smap->map.max_entries,
|
|
|
|
|
smap->map.numa_node);
|
2016-03-08 13:57:17 +08:00
|
|
|
if (!smap->elems)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
err = pcpu_freelist_init(&smap->freelist);
|
|
|
|
|
if (err)
|
|
|
|
|
goto free_elems;
|
|
|
|
|
|
|
|
|
|
pcpu_freelist_populate(&smap->freelist, smap->elems, elem_size,
|
|
|
|
|
smap->map.max_entries);
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
free_elems:
|
bpf: don't trigger OOM killer under pressure with map alloc
This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
that are to be used for map allocations. Using kmalloc() for very large
allocations can cause excessive work within the page allocator, so i) fall
back earlier to vmalloc() when the attempt is considered costly anyway,
and even more importantly ii) don't trigger OOM killer with any of the
allocators.
Since this is based on a user space request, for example, when creating
maps with element pre-allocation, we really want such requests to fail
instead of killing other user space processes.
Also, don't spam the kernel log with warnings should any of the allocations
fail under pressure. Given that, we can make backend selection in
bpf_map_area_alloc() generic, and convert all maps over to use this API
for spots with potentially large allocation requests.
Note, replacing the one kmalloc_array() is fine as overflow checks happen
earlier in htab_map_alloc(), since it must also protect the multiplication
for vmalloc() should kmalloc_array() fail.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-18 22:14:17 +08:00
|
|
|
bpf_map_area_free(smap->elems);
|
2016-03-08 13:57:17 +08:00
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-18 11:58:58 +08:00
|
|
|
/* Called from syscall */
|
|
|
|
|
static struct bpf_map *stack_map_alloc(union bpf_attr *attr)
|
|
|
|
|
{
|
|
|
|
|
u32 value_size = attr->value_size;
|
|
|
|
|
struct bpf_stack_map *smap;
|
|
|
|
|
u64 cost, n_buckets;
|
|
|
|
|
int err;
|
|
|
|
|
|
2017-10-19 04:00:22 +08:00
|
|
|
if (attr->map_flags & ~STACK_CREATE_FLAG_MASK)
|
2016-03-08 13:57:16 +08:00
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
|
2016-02-18 11:58:58 +08:00
|
|
|
/* check sanity of attributes */
|
|
|
|
|
if (attr->max_entries == 0 || attr->key_size != 4 ||
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
value_size < 8 || value_size % 8)
|
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
|
|
|
|
|
BUILD_BUG_ON(sizeof(struct bpf_stack_build_id) % sizeof(u64));
|
|
|
|
|
if (attr->map_flags & BPF_F_STACK_BUILD_ID) {
|
|
|
|
|
if (value_size % sizeof(struct bpf_stack_build_id) ||
|
|
|
|
|
value_size / sizeof(struct bpf_stack_build_id)
|
|
|
|
|
> sysctl_perf_event_max_stack)
|
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
} else if (value_size / 8 > sysctl_perf_event_max_stack)
|
2016-02-18 11:58:58 +08:00
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
|
|
|
|
|
/* hash table size must be power of 2 */
|
|
|
|
|
n_buckets = roundup_pow_of_two(attr->max_entries);
|
2021-01-27 14:36:53 +08:00
|
|
|
if (!n_buckets)
|
|
|
|
|
return ERR_PTR(-E2BIG);
|
2016-02-18 11:58:58 +08:00
|
|
|
|
|
|
|
|
cost = n_buckets * sizeof(struct stack_map_bucket *) + sizeof(*smap);
|
2017-08-19 02:28:00 +08:00
|
|
|
smap = bpf_map_area_alloc(cost, bpf_map_attr_numa_node(attr));
|
2020-12-02 05:58:55 +08:00
|
|
|
if (!smap)
|
bpf: don't trigger OOM killer under pressure with map alloc
This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
that are to be used for map allocations. Using kmalloc() for very large
allocations can cause excessive work within the page allocator, so i) fall
back earlier to vmalloc() when the attempt is considered costly anyway,
and even more importantly ii) don't trigger OOM killer with any of the
allocators.
Since this is based on a user space request, for example, when creating
maps with element pre-allocation, we really want such requests to fail
instead of killing other user space processes.
Also, don't spam the kernel log with warnings should any of the allocations
fail under pressure. Given that, we can make backend selection in
bpf_map_area_alloc() generic, and convert all maps over to use this API
for spots with potentially large allocation requests.
Note, replacing the one kmalloc_array() is fine as overflow checks happen
earlier in htab_map_alloc(), since it must also protect the multiplication
for vmalloc() should kmalloc_array() fail.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-18 22:14:17 +08:00
|
|
|
return ERR_PTR(-ENOMEM);
|
2016-02-18 11:58:58 +08:00
|
|
|
|
2018-01-12 12:29:06 +08:00
|
|
|
bpf_map_init_from_attr(&smap->map, attr);
|
2016-02-18 11:58:58 +08:00
|
|
|
smap->n_buckets = n_buckets;
|
2016-03-08 13:57:17 +08:00
|
|
|
|
2016-04-29 00:16:33 +08:00
|
|
|
err = get_callchain_buffers(sysctl_perf_event_max_stack);
|
2016-02-18 11:58:58 +08:00
|
|
|
if (err)
|
2020-12-02 05:58:55 +08:00
|
|
|
goto free_smap;
|
2016-02-18 11:58:58 +08:00
|
|
|
|
2016-03-08 13:57:17 +08:00
|
|
|
err = prealloc_elems_and_freelist(smap);
|
|
|
|
|
if (err)
|
|
|
|
|
goto put_buffers;
|
|
|
|
|
|
2016-02-18 11:58:58 +08:00
|
|
|
return &smap->map;
|
|
|
|
|
|
2016-03-08 13:57:17 +08:00
|
|
|
put_buffers:
|
|
|
|
|
put_callchain_buffers();
|
2020-12-02 05:58:55 +08:00
|
|
|
free_smap:
|
bpf: don't trigger OOM killer under pressure with map alloc
This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
that are to be used for map allocations. Using kmalloc() for very large
allocations can cause excessive work within the page allocator, so i) fall
back earlier to vmalloc() when the attempt is considered costly anyway,
and even more importantly ii) don't trigger OOM killer with any of the
allocators.
Since this is based on a user space request, for example, when creating
maps with element pre-allocation, we really want such requests to fail
instead of killing other user space processes.
Also, don't spam the kernel log with warnings should any of the allocations
fail under pressure. Given that, we can make backend selection in
bpf_map_area_alloc() generic, and convert all maps over to use this API
for spots with potentially large allocation requests.
Note, replacing the one kmalloc_array() is fine as overflow checks happen
earlier in htab_map_alloc(), since it must also protect the multiplication
for vmalloc() should kmalloc_array() fail.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-18 22:14:17 +08:00
|
|
|
bpf_map_area_free(smap);
|
2016-02-18 11:58:58 +08:00
|
|
|
return ERR_PTR(err);
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-29 13:28:07 +08:00
|
|
|
static void stack_map_get_build_id_offset(struct bpf_stack_build_id *id_offs,
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
u64 *ips, u32 trace_nr, bool user)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
2021-11-06 07:23:29 +08:00
|
|
|
struct mmap_unlock_irq_work *work = NULL;
|
|
|
|
|
bool irq_work_busy = bpf_mmap_unlock_get_irq_work(&work);
|
2022-02-24 08:05:31 +08:00
|
|
|
struct vm_area_struct *vma, *prev_vma = NULL;
|
|
|
|
|
const char *prev_build_id;
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
|
2021-11-06 07:23:29 +08:00
|
|
|
/* If the irq_work is in use, fall back to report ips. Same
|
|
|
|
|
* fallback is used for kernel stack (!user) on a stackmap with
|
|
|
|
|
* build_id.
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
*/
|
2018-05-08 01:50:48 +08:00
|
|
|
if (!user || !current || !current->mm || irq_work_busy ||
|
2021-09-09 23:49:59 +08:00
|
|
|
!mmap_read_trylock(current->mm)) {
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
/* cannot access current->mm, fall back to ips */
|
|
|
|
|
for (i = 0; i < trace_nr; i++) {
|
|
|
|
|
id_offs[i].status = BPF_STACK_BUILD_ID_IP;
|
|
|
|
|
id_offs[i].ip = ips[i];
|
2021-01-14 21:40:42 +08:00
|
|
|
memset(id_offs[i].build_id, 0, BUILD_ID_SIZE_MAX);
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
}
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < trace_nr; i++) {
|
2022-02-24 08:05:31 +08:00
|
|
|
if (range_in_vma(prev_vma, ips[i], ips[i])) {
|
|
|
|
|
vma = prev_vma;
|
|
|
|
|
memcpy(id_offs[i].build_id, prev_build_id,
|
|
|
|
|
BUILD_ID_SIZE_MAX);
|
|
|
|
|
goto build_id_valid;
|
|
|
|
|
}
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
vma = find_vma(current->mm, ips[i]);
|
2021-01-14 21:40:43 +08:00
|
|
|
if (!vma || build_id_parse(vma, id_offs[i].build_id, NULL)) {
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
/* per entry fall back to ips */
|
|
|
|
|
id_offs[i].status = BPF_STACK_BUILD_ID_IP;
|
|
|
|
|
id_offs[i].ip = ips[i];
|
2021-01-14 21:40:42 +08:00
|
|
|
memset(id_offs[i].build_id, 0, BUILD_ID_SIZE_MAX);
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
continue;
|
|
|
|
|
}
|
2022-02-24 08:05:31 +08:00
|
|
|
build_id_valid:
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
id_offs[i].offset = (vma->vm_pgoff << PAGE_SHIFT) + ips[i]
|
|
|
|
|
- vma->vm_start;
|
|
|
|
|
id_offs[i].status = BPF_STACK_BUILD_ID_VALID;
|
2022-02-24 08:05:31 +08:00
|
|
|
prev_vma = vma;
|
|
|
|
|
prev_build_id = id_offs[i].build_id;
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
}
|
2021-11-06 07:23:29 +08:00
|
|
|
bpf_mmap_unlock_mm(work, current->mm);
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
}
|
|
|
|
|
|
2020-06-30 14:28:44 +08:00
|
|
|
static struct perf_callchain_entry *
|
2022-03-15 02:20:41 +08:00
|
|
|
get_callchain_entry_for_task(struct task_struct *task, u32 max_depth)
|
2020-06-30 14:28:44 +08:00
|
|
|
{
|
2020-07-03 10:45:37 +08:00
|
|
|
#ifdef CONFIG_STACKTRACE
|
2020-06-30 14:28:44 +08:00
|
|
|
struct perf_callchain_entry *entry;
|
|
|
|
|
int rctx;
|
|
|
|
|
|
|
|
|
|
entry = get_callchain_entry(&rctx);
|
|
|
|
|
|
|
|
|
|
if (!entry)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
2022-03-15 02:20:41 +08:00
|
|
|
entry->nr = stack_trace_save_tsk(task, (unsigned long *)entry->ip,
|
|
|
|
|
max_depth, 0);
|
2020-06-30 14:28:44 +08:00
|
|
|
|
|
|
|
|
/* stack_trace_save_tsk() works on unsigned long array, while
|
|
|
|
|
* perf_callchain_entry uses u64 array. For 32-bit systems, it is
|
|
|
|
|
* necessary to fix this mismatch.
|
|
|
|
|
*/
|
|
|
|
|
if (__BITS_PER_LONG != 64) {
|
|
|
|
|
unsigned long *from = (unsigned long *) entry->ip;
|
|
|
|
|
u64 *to = entry->ip;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
/* copy data from the end to avoid using extra buffer */
|
2022-03-15 02:20:41 +08:00
|
|
|
for (i = entry->nr - 1; i >= 0; i--)
|
2020-06-30 14:28:44 +08:00
|
|
|
to[i] = (u64)(from[i]);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
put_callchain_entry(rctx);
|
|
|
|
|
|
|
|
|
|
return entry;
|
2020-07-03 10:45:37 +08:00
|
|
|
#else /* CONFIG_STACKTRACE */
|
|
|
|
|
return NULL;
|
|
|
|
|
#endif
|
2020-06-30 14:28:44 +08:00
|
|
|
}
|
|
|
|
|
|
2020-07-24 02:06:44 +08:00
|
|
|
static long __bpf_get_stackid(struct bpf_map *map,
|
|
|
|
|
struct perf_callchain_entry *trace, u64 flags)
|
2016-02-18 11:58:58 +08:00
|
|
|
{
|
|
|
|
|
struct bpf_stack_map *smap = container_of(map, struct bpf_stack_map, map);
|
|
|
|
|
struct stack_map_bucket *bucket, *new_bucket, *old_bucket;
|
|
|
|
|
u32 skip = flags & BPF_F_SKIP_FIELD_MASK;
|
|
|
|
|
u32 hash, id, trace_nr, trace_len;
|
|
|
|
|
bool user = flags & BPF_F_USER_STACK;
|
|
|
|
|
u64 *ips;
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
bool hash_matches;
|
2016-02-18 11:58:58 +08:00
|
|
|
|
2022-03-15 02:20:41 +08:00
|
|
|
if (trace->nr <= skip)
|
2016-02-18 11:58:58 +08:00
|
|
|
/* skipping more than usable stack trace */
|
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
2022-03-15 02:20:41 +08:00
|
|
|
trace_nr = trace->nr - skip;
|
2016-02-18 11:58:58 +08:00
|
|
|
trace_len = trace_nr * sizeof(u64);
|
2022-03-15 02:20:41 +08:00
|
|
|
ips = trace->ip + skip;
|
2016-02-18 11:58:58 +08:00
|
|
|
hash = jhash2((u32 *)ips, trace_len / sizeof(u32), 0);
|
|
|
|
|
id = hash & (smap->n_buckets - 1);
|
2016-03-08 13:57:17 +08:00
|
|
|
bucket = READ_ONCE(smap->buckets[id]);
|
2016-02-18 11:58:58 +08:00
|
|
|
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
hash_matches = bucket && bucket->hash == hash;
|
|
|
|
|
/* fast cmp */
|
|
|
|
|
if (hash_matches && flags & BPF_F_FAST_STACK_CMP)
|
|
|
|
|
return id;
|
|
|
|
|
|
|
|
|
|
if (stack_map_use_build_id(map)) {
|
|
|
|
|
/* for build_id+offset, pop a bucket before slow cmp */
|
|
|
|
|
new_bucket = (struct stack_map_bucket *)
|
|
|
|
|
pcpu_freelist_pop(&smap->freelist);
|
|
|
|
|
if (unlikely(!new_bucket))
|
|
|
|
|
return -ENOMEM;
|
2018-04-29 13:28:07 +08:00
|
|
|
new_bucket->nr = trace_nr;
|
|
|
|
|
stack_map_get_build_id_offset(
|
|
|
|
|
(struct bpf_stack_build_id *)new_bucket->data,
|
|
|
|
|
ips, trace_nr, user);
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
trace_len = trace_nr * sizeof(struct bpf_stack_build_id);
|
|
|
|
|
if (hash_matches && bucket->nr == trace_nr &&
|
|
|
|
|
memcmp(bucket->data, new_bucket->data, trace_len) == 0) {
|
|
|
|
|
pcpu_freelist_push(&smap->freelist, &new_bucket->fnode);
|
2016-02-18 11:58:58 +08:00
|
|
|
return id;
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
}
|
|
|
|
|
if (bucket && !(flags & BPF_F_REUSE_STACKID)) {
|
|
|
|
|
pcpu_freelist_push(&smap->freelist, &new_bucket->fnode);
|
|
|
|
|
return -EEXIST;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
if (hash_matches && bucket->nr == trace_nr &&
|
|
|
|
|
memcmp(bucket->data, ips, trace_len) == 0)
|
2016-02-18 11:58:58 +08:00
|
|
|
return id;
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
if (bucket && !(flags & BPF_F_REUSE_STACKID))
|
|
|
|
|
return -EEXIST;
|
|
|
|
|
|
|
|
|
|
new_bucket = (struct stack_map_bucket *)
|
|
|
|
|
pcpu_freelist_pop(&smap->freelist);
|
|
|
|
|
if (unlikely(!new_bucket))
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
memcpy(new_bucket->data, ips, trace_len);
|
2016-02-18 11:58:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
new_bucket->hash = hash;
|
|
|
|
|
new_bucket->nr = trace_nr;
|
|
|
|
|
|
|
|
|
|
old_bucket = xchg(&smap->buckets[id], new_bucket);
|
|
|
|
|
if (old_bucket)
|
2016-03-08 13:57:17 +08:00
|
|
|
pcpu_freelist_push(&smap->freelist, &old_bucket->fnode);
|
2016-02-18 11:58:58 +08:00
|
|
|
return id;
|
|
|
|
|
}
|
|
|
|
|
|
2020-07-24 02:06:44 +08:00
|
|
|
BPF_CALL_3(bpf_get_stackid, struct pt_regs *, regs, struct bpf_map *, map,
|
|
|
|
|
u64, flags)
|
|
|
|
|
{
|
|
|
|
|
u32 max_depth = map->value_size / stack_map_data_size(map);
|
2022-03-15 02:20:41 +08:00
|
|
|
u32 skip = flags & BPF_F_SKIP_FIELD_MASK;
|
2020-07-24 02:06:44 +08:00
|
|
|
bool user = flags & BPF_F_USER_STACK;
|
|
|
|
|
struct perf_callchain_entry *trace;
|
|
|
|
|
bool kernel = !user;
|
|
|
|
|
|
|
|
|
|
if (unlikely(flags & ~(BPF_F_SKIP_FIELD_MASK | BPF_F_USER_STACK |
|
|
|
|
|
BPF_F_FAST_STACK_CMP | BPF_F_REUSE_STACKID)))
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
2022-03-15 02:20:41 +08:00
|
|
|
max_depth += skip;
|
|
|
|
|
if (max_depth > sysctl_perf_event_max_stack)
|
|
|
|
|
max_depth = sysctl_perf_event_max_stack;
|
|
|
|
|
|
|
|
|
|
trace = get_perf_callchain(regs, 0, kernel, user, max_depth,
|
|
|
|
|
false, false);
|
2020-07-24 02:06:44 +08:00
|
|
|
|
|
|
|
|
if (unlikely(!trace))
|
|
|
|
|
/* couldn't fetch the stack trace */
|
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
|
|
return __bpf_get_stackid(map, trace, flags);
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-18 11:58:58 +08:00
|
|
|
const struct bpf_func_proto bpf_get_stackid_proto = {
|
|
|
|
|
.func = bpf_get_stackid,
|
|
|
|
|
.gpl_only = true,
|
|
|
|
|
.ret_type = RET_INTEGER,
|
|
|
|
|
.arg1_type = ARG_PTR_TO_CTX,
|
|
|
|
|
.arg2_type = ARG_CONST_MAP_PTR,
|
|
|
|
|
.arg3_type = ARG_ANYTHING,
|
|
|
|
|
};
|
|
|
|
|
|
2020-07-24 02:06:44 +08:00
|
|
|
static __u64 count_kernel_ip(struct perf_callchain_entry *trace)
|
|
|
|
|
{
|
|
|
|
|
__u64 nr_kernel = 0;
|
|
|
|
|
|
|
|
|
|
while (nr_kernel < trace->nr) {
|
|
|
|
|
if (trace->ip[nr_kernel] == PERF_CONTEXT_USER)
|
|
|
|
|
break;
|
|
|
|
|
nr_kernel++;
|
|
|
|
|
}
|
|
|
|
|
return nr_kernel;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BPF_CALL_3(bpf_get_stackid_pe, struct bpf_perf_event_data_kern *, ctx,
|
|
|
|
|
struct bpf_map *, map, u64, flags)
|
|
|
|
|
{
|
|
|
|
|
struct perf_event *event = ctx->event;
|
|
|
|
|
struct perf_callchain_entry *trace;
|
|
|
|
|
bool kernel, user;
|
|
|
|
|
__u64 nr_kernel;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
/* perf_sample_data doesn't have callchain, use bpf_get_stackid */
|
2022-09-09 05:41:03 +08:00
|
|
|
if (!(event->attr.sample_type & PERF_SAMPLE_CALLCHAIN))
|
2020-07-24 02:06:44 +08:00
|
|
|
return bpf_get_stackid((unsigned long)(ctx->regs),
|
|
|
|
|
(unsigned long) map, flags, 0, 0);
|
|
|
|
|
|
|
|
|
|
if (unlikely(flags & ~(BPF_F_SKIP_FIELD_MASK | BPF_F_USER_STACK |
|
|
|
|
|
BPF_F_FAST_STACK_CMP | BPF_F_REUSE_STACKID)))
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
user = flags & BPF_F_USER_STACK;
|
|
|
|
|
kernel = !user;
|
|
|
|
|
|
|
|
|
|
trace = ctx->data->callchain;
|
|
|
|
|
if (unlikely(!trace))
|
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
|
|
nr_kernel = count_kernel_ip(trace);
|
|
|
|
|
|
|
|
|
|
if (kernel) {
|
|
|
|
|
__u64 nr = trace->nr;
|
|
|
|
|
|
|
|
|
|
trace->nr = nr_kernel;
|
|
|
|
|
ret = __bpf_get_stackid(map, trace, flags);
|
|
|
|
|
|
|
|
|
|
/* restore nr */
|
|
|
|
|
trace->nr = nr;
|
|
|
|
|
} else { /* user */
|
|
|
|
|
u64 skip = flags & BPF_F_SKIP_FIELD_MASK;
|
|
|
|
|
|
|
|
|
|
skip += nr_kernel;
|
|
|
|
|
if (skip > BPF_F_SKIP_FIELD_MASK)
|
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
|
|
flags = (flags & ~BPF_F_SKIP_FIELD_MASK) | skip;
|
|
|
|
|
ret = __bpf_get_stackid(map, trace, flags);
|
|
|
|
|
}
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const struct bpf_func_proto bpf_get_stackid_proto_pe = {
|
|
|
|
|
.func = bpf_get_stackid_pe,
|
|
|
|
|
.gpl_only = false,
|
|
|
|
|
.ret_type = RET_INTEGER,
|
|
|
|
|
.arg1_type = ARG_PTR_TO_CTX,
|
|
|
|
|
.arg2_type = ARG_CONST_MAP_PTR,
|
|
|
|
|
.arg3_type = ARG_ANYTHING,
|
|
|
|
|
};
|
|
|
|
|
|
2020-06-30 14:28:44 +08:00
|
|
|
static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
|
2020-07-24 02:06:44 +08:00
|
|
|
struct perf_callchain_entry *trace_in,
|
2020-06-30 14:28:44 +08:00
|
|
|
void *buf, u32 size, u64 flags)
|
2018-04-29 13:28:08 +08:00
|
|
|
{
|
2022-03-15 02:20:41 +08:00
|
|
|
u32 trace_nr, copy_len, elem_size, num_elem, max_depth;
|
2018-04-29 13:28:08 +08:00
|
|
|
bool user_build_id = flags & BPF_F_USER_BUILD_ID;
|
2023-11-08 19:23:34 +08:00
|
|
|
bool crosstask = task && task != current;
|
2018-04-29 13:28:08 +08:00
|
|
|
u32 skip = flags & BPF_F_SKIP_FIELD_MASK;
|
|
|
|
|
bool user = flags & BPF_F_USER_STACK;
|
|
|
|
|
struct perf_callchain_entry *trace;
|
|
|
|
|
bool kernel = !user;
|
|
|
|
|
int err = -EINVAL;
|
|
|
|
|
u64 *ips;
|
|
|
|
|
|
|
|
|
|
if (unlikely(flags & ~(BPF_F_SKIP_FIELD_MASK | BPF_F_USER_STACK |
|
|
|
|
|
BPF_F_USER_BUILD_ID)))
|
|
|
|
|
goto clear;
|
|
|
|
|
if (kernel && user_build_id)
|
|
|
|
|
goto clear;
|
|
|
|
|
|
|
|
|
|
elem_size = (user && user_build_id) ? sizeof(struct bpf_stack_build_id)
|
|
|
|
|
: sizeof(u64);
|
|
|
|
|
if (unlikely(size % elem_size))
|
|
|
|
|
goto clear;
|
|
|
|
|
|
2020-06-30 14:28:44 +08:00
|
|
|
/* cannot get valid user stack for task without user_mode regs */
|
|
|
|
|
if (task && user && !user_mode(regs))
|
|
|
|
|
goto err_fault;
|
|
|
|
|
|
2023-11-08 19:23:34 +08:00
|
|
|
/* get_perf_callchain does not support crosstask user stack walking
|
|
|
|
|
* but returns an empty stack instead of NULL.
|
|
|
|
|
*/
|
|
|
|
|
if (crosstask && user) {
|
|
|
|
|
err = -EOPNOTSUPP;
|
|
|
|
|
goto clear;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-29 13:28:08 +08:00
|
|
|
num_elem = size / elem_size;
|
2022-03-15 02:20:41 +08:00
|
|
|
max_depth = num_elem + skip;
|
|
|
|
|
if (sysctl_perf_event_max_stack < max_depth)
|
|
|
|
|
max_depth = sysctl_perf_event_max_stack;
|
2020-06-30 14:28:44 +08:00
|
|
|
|
2020-07-24 02:06:44 +08:00
|
|
|
if (trace_in)
|
|
|
|
|
trace = trace_in;
|
|
|
|
|
else if (kernel && task)
|
2022-03-15 02:20:41 +08:00
|
|
|
trace = get_callchain_entry_for_task(task, max_depth);
|
2020-06-30 14:28:44 +08:00
|
|
|
else
|
2022-03-15 02:20:41 +08:00
|
|
|
trace = get_perf_callchain(regs, 0, kernel, user, max_depth,
|
2023-11-08 19:23:34 +08:00
|
|
|
crosstask, false);
|
2018-04-29 13:28:08 +08:00
|
|
|
if (unlikely(!trace))
|
|
|
|
|
goto err_fault;
|
|
|
|
|
|
2022-03-15 02:20:41 +08:00
|
|
|
if (trace->nr < skip)
|
2018-04-29 13:28:08 +08:00
|
|
|
goto err_fault;
|
|
|
|
|
|
2022-03-15 02:20:41 +08:00
|
|
|
trace_nr = trace->nr - skip;
|
2018-04-29 13:28:08 +08:00
|
|
|
trace_nr = (trace_nr <= num_elem) ? trace_nr : num_elem;
|
|
|
|
|
copy_len = trace_nr * elem_size;
|
2022-03-15 02:20:41 +08:00
|
|
|
|
|
|
|
|
ips = trace->ip + skip;
|
2018-04-29 13:28:08 +08:00
|
|
|
if (user && user_build_id)
|
|
|
|
|
stack_map_get_build_id_offset(buf, ips, trace_nr, user);
|
|
|
|
|
else
|
|
|
|
|
memcpy(buf, ips, copy_len);
|
|
|
|
|
|
|
|
|
|
if (size > copy_len)
|
|
|
|
|
memset(buf + copy_len, 0, size - copy_len);
|
|
|
|
|
return copy_len;
|
|
|
|
|
|
|
|
|
|
err_fault:
|
|
|
|
|
err = -EFAULT;
|
|
|
|
|
clear:
|
|
|
|
|
memset(buf, 0, size);
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2020-06-30 14:28:44 +08:00
|
|
|
BPF_CALL_4(bpf_get_stack, struct pt_regs *, regs, void *, buf, u32, size,
|
|
|
|
|
u64, flags)
|
|
|
|
|
{
|
2020-07-24 02:06:44 +08:00
|
|
|
return __bpf_get_stack(regs, NULL, NULL, buf, size, flags);
|
2020-06-30 14:28:44 +08:00
|
|
|
}
|
|
|
|
|
|
2018-04-29 13:28:08 +08:00
|
|
|
const struct bpf_func_proto bpf_get_stack_proto = {
|
|
|
|
|
.func = bpf_get_stack,
|
|
|
|
|
.gpl_only = true,
|
|
|
|
|
.ret_type = RET_INTEGER,
|
|
|
|
|
.arg1_type = ARG_PTR_TO_CTX,
|
|
|
|
|
.arg2_type = ARG_PTR_TO_UNINIT_MEM,
|
|
|
|
|
.arg3_type = ARG_CONST_SIZE_OR_ZERO,
|
|
|
|
|
.arg4_type = ARG_ANYTHING,
|
|
|
|
|
};
|
|
|
|
|
|
2020-06-30 14:28:44 +08:00
|
|
|
BPF_CALL_4(bpf_get_task_stack, struct task_struct *, task, void *, buf,
|
|
|
|
|
u32, size, u64, flags)
|
|
|
|
|
{
|
2021-04-01 08:07:47 +08:00
|
|
|
struct pt_regs *regs;
|
2022-01-06 19:45:05 +08:00
|
|
|
long res = -EINVAL;
|
2020-06-30 14:28:44 +08:00
|
|
|
|
2021-04-01 08:07:47 +08:00
|
|
|
if (!try_get_task_stack(task))
|
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
|
|
regs = task_pt_regs(task);
|
2022-01-06 19:45:05 +08:00
|
|
|
if (regs)
|
|
|
|
|
res = __bpf_get_stack(regs, task, NULL, buf, size, flags);
|
2021-04-01 08:07:47 +08:00
|
|
|
put_task_stack(task);
|
|
|
|
|
|
|
|
|
|
return res;
|
2020-06-30 14:28:44 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const struct bpf_func_proto bpf_get_task_stack_proto = {
|
|
|
|
|
.func = bpf_get_task_stack,
|
|
|
|
|
.gpl_only = false,
|
|
|
|
|
.ret_type = RET_INTEGER,
|
|
|
|
|
.arg1_type = ARG_PTR_TO_BTF_ID,
|
2021-11-12 23:02:43 +08:00
|
|
|
.arg1_btf_id = &btf_tracing_ids[BTF_TRACING_TYPE_TASK],
|
2020-06-30 14:28:44 +08:00
|
|
|
.arg2_type = ARG_PTR_TO_UNINIT_MEM,
|
|
|
|
|
.arg3_type = ARG_CONST_SIZE_OR_ZERO,
|
|
|
|
|
.arg4_type = ARG_ANYTHING,
|
|
|
|
|
};
|
|
|
|
|
|
2020-07-24 02:06:44 +08:00
|
|
|
BPF_CALL_4(bpf_get_stack_pe, struct bpf_perf_event_data_kern *, ctx,
|
|
|
|
|
void *, buf, u32, size, u64, flags)
|
|
|
|
|
{
|
2020-07-25 04:05:02 +08:00
|
|
|
struct pt_regs *regs = (struct pt_regs *)(ctx->regs);
|
2020-07-24 02:06:44 +08:00
|
|
|
struct perf_event *event = ctx->event;
|
|
|
|
|
struct perf_callchain_entry *trace;
|
|
|
|
|
bool kernel, user;
|
|
|
|
|
int err = -EINVAL;
|
|
|
|
|
__u64 nr_kernel;
|
|
|
|
|
|
2022-09-09 05:41:03 +08:00
|
|
|
if (!(event->attr.sample_type & PERF_SAMPLE_CALLCHAIN))
|
2020-07-25 04:05:02 +08:00
|
|
|
return __bpf_get_stack(regs, NULL, NULL, buf, size, flags);
|
2020-07-24 02:06:44 +08:00
|
|
|
|
|
|
|
|
if (unlikely(flags & ~(BPF_F_SKIP_FIELD_MASK | BPF_F_USER_STACK |
|
|
|
|
|
BPF_F_USER_BUILD_ID)))
|
|
|
|
|
goto clear;
|
|
|
|
|
|
|
|
|
|
user = flags & BPF_F_USER_STACK;
|
|
|
|
|
kernel = !user;
|
|
|
|
|
|
|
|
|
|
err = -EFAULT;
|
|
|
|
|
trace = ctx->data->callchain;
|
|
|
|
|
if (unlikely(!trace))
|
|
|
|
|
goto clear;
|
|
|
|
|
|
|
|
|
|
nr_kernel = count_kernel_ip(trace);
|
|
|
|
|
|
|
|
|
|
if (kernel) {
|
|
|
|
|
__u64 nr = trace->nr;
|
|
|
|
|
|
|
|
|
|
trace->nr = nr_kernel;
|
2020-07-25 04:05:02 +08:00
|
|
|
err = __bpf_get_stack(regs, NULL, trace, buf, size, flags);
|
2020-07-24 02:06:44 +08:00
|
|
|
|
|
|
|
|
/* restore nr */
|
|
|
|
|
trace->nr = nr;
|
|
|
|
|
} else { /* user */
|
|
|
|
|
u64 skip = flags & BPF_F_SKIP_FIELD_MASK;
|
|
|
|
|
|
|
|
|
|
skip += nr_kernel;
|
|
|
|
|
if (skip > BPF_F_SKIP_FIELD_MASK)
|
|
|
|
|
goto clear;
|
|
|
|
|
|
|
|
|
|
flags = (flags & ~BPF_F_SKIP_FIELD_MASK) | skip;
|
2020-07-25 04:05:02 +08:00
|
|
|
err = __bpf_get_stack(regs, NULL, trace, buf, size, flags);
|
2020-07-24 02:06:44 +08:00
|
|
|
}
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
clear:
|
|
|
|
|
memset(buf, 0, size);
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const struct bpf_func_proto bpf_get_stack_proto_pe = {
|
|
|
|
|
.func = bpf_get_stack_pe,
|
|
|
|
|
.gpl_only = true,
|
|
|
|
|
.ret_type = RET_INTEGER,
|
|
|
|
|
.arg1_type = ARG_PTR_TO_CTX,
|
|
|
|
|
.arg2_type = ARG_PTR_TO_UNINIT_MEM,
|
|
|
|
|
.arg3_type = ARG_CONST_SIZE_OR_ZERO,
|
|
|
|
|
.arg4_type = ARG_ANYTHING,
|
|
|
|
|
};
|
|
|
|
|
|
2016-03-08 13:57:17 +08:00
|
|
|
/* Called from eBPF program */
|
2016-02-18 11:58:58 +08:00
|
|
|
static void *stack_map_lookup_elem(struct bpf_map *map, void *key)
|
2016-03-08 13:57:17 +08:00
|
|
|
{
|
2018-10-09 09:04:50 +08:00
|
|
|
return ERR_PTR(-EOPNOTSUPP);
|
2016-03-08 13:57:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Called from syscall */
|
|
|
|
|
int bpf_stackmap_copy(struct bpf_map *map, void *key, void *value)
|
2016-02-18 11:58:58 +08:00
|
|
|
{
|
|
|
|
|
struct bpf_stack_map *smap = container_of(map, struct bpf_stack_map, map);
|
2016-03-08 13:57:17 +08:00
|
|
|
struct stack_map_bucket *bucket, *old_bucket;
|
|
|
|
|
u32 id = *(u32 *)key, trace_len;
|
2016-02-18 11:58:58 +08:00
|
|
|
|
|
|
|
|
if (unlikely(id >= smap->n_buckets))
|
2016-03-08 13:57:17 +08:00
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
|
|
bucket = xchg(&smap->buckets[id], NULL);
|
|
|
|
|
if (!bucket)
|
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
bpf: extend stackmap to save binary_build_id+offset instead of address
Currently, bpf stackmap store address for each entry in the call trace.
To map these addresses to user space files, it is necessary to maintain
the mapping from these virtual address to symbols in the binary. Usually,
the user space profiler (such as perf) has to scan /proc/pid/maps at the
beginning of profiling, and monitor mmap2() calls afterwards. Given the
cost of maintaining the address map, this solution is not practical for
system wide profiling that is always on.
This patch tries to solve this problem with a variation of stackmap. This
variation is enabled by flag BPF_F_STACK_BUILD_ID. Instead of storing
addresses, the variation stores ELF file build_id + offset.
Build ID is a 20-byte unique identifier for ELF files. The following
command shows the Build ID of /bin/bash:
[user@]$ readelf -n /bin/bash
...
Build ID: XXXXXXXXXX
...
With BPF_F_STACK_BUILD_ID, bpf_get_stackid() tries to parse Build ID
for each entry in the call trace, and translate it into the following
struct:
struct bpf_stack_build_id_offset {
__s32 status;
unsigned char build_id[BPF_BUILD_ID_SIZE];
union {
__u64 offset;
__u64 ip;
};
};
The search of build_id is limited to the first page of the file, and this
page should be in page cache. Otherwise, we fallback to store ip for this
entry (ip field in struct bpf_stack_build_id_offset). This requires the
build_id to be stored in the first page. A quick survey of binary and
dynamic library files in a few different systems shows that almost all
binary and dynamic library files have build_id in the first page.
Build_id is only meaningful for user stack. If a kernel stack is added to
a stackmap with BPF_F_STACK_BUILD_ID, it will automatically fallback to
only store ip (status == BPF_STACK_BUILD_ID_IP). Similarly, if build_id
lookup failed for some reason, it will also fallback to store ip.
User space can access struct bpf_stack_build_id_offset with bpf
syscall BPF_MAP_LOOKUP_ELEM. It is necessary for user space to
maintain mapping from build id to binary files. This mostly static
mapping is much easier to maintain than per process address maps.
Note: Stackmap with build_id only works in non-nmi context at this time.
This is because we need to take mm->mmap_sem for find_vma(). If this
changes, we would like to allow build_id lookup in nmi context.
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-03-15 01:23:21 +08:00
|
|
|
trace_len = bucket->nr * stack_map_data_size(map);
|
|
|
|
|
memcpy(value, bucket->data, trace_len);
|
2016-03-08 13:57:17 +08:00
|
|
|
memset(value + trace_len, 0, map->value_size - trace_len);
|
|
|
|
|
|
|
|
|
|
old_bucket = xchg(&smap->buckets[id], bucket);
|
|
|
|
|
if (old_bucket)
|
|
|
|
|
pcpu_freelist_push(&smap->freelist, &old_bucket->fnode);
|
|
|
|
|
return 0;
|
2016-02-18 11:58:58 +08:00
|
|
|
}
|
|
|
|
|
|
2018-01-05 05:55:03 +08:00
|
|
|
static int stack_map_get_next_key(struct bpf_map *map, void *key,
|
|
|
|
|
void *next_key)
|
2016-02-18 11:58:58 +08:00
|
|
|
{
|
2018-01-05 05:55:03 +08:00
|
|
|
struct bpf_stack_map *smap = container_of(map,
|
|
|
|
|
struct bpf_stack_map, map);
|
|
|
|
|
u32 id;
|
|
|
|
|
|
|
|
|
|
WARN_ON_ONCE(!rcu_read_lock_held());
|
|
|
|
|
|
|
|
|
|
if (!key) {
|
|
|
|
|
id = 0;
|
|
|
|
|
} else {
|
|
|
|
|
id = *(u32 *)key;
|
|
|
|
|
if (id >= smap->n_buckets || !smap->buckets[id])
|
|
|
|
|
id = 0;
|
|
|
|
|
else
|
|
|
|
|
id++;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
while (id < smap->n_buckets && !smap->buckets[id])
|
|
|
|
|
id++;
|
|
|
|
|
|
|
|
|
|
if (id >= smap->n_buckets)
|
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
|
|
*(u32 *)next_key = id;
|
|
|
|
|
return 0;
|
2016-02-18 11:58:58 +08:00
|
|
|
}
|
|
|
|
|
|
bpf: return long from bpf_map_ops funcs
This patch changes the return types of bpf_map_ops functions to long, where
previously int was returned. Using long allows for bpf programs to maintain
the sign bit in the absence of sign extension during situations where
inlined bpf helper funcs make calls to the bpf_map_ops funcs and a negative
error is returned.
The definitions of the helper funcs are generated from comments in the bpf
uapi header at `include/uapi/linux/bpf.h`. The return type of these
helpers was previously changed from int to long in commit bdb7b79b4ce8. For
any case where one of the map helpers call the bpf_map_ops funcs that are
still returning 32-bit int, a compiler might not include sign extension
instructions to properly convert the 32-bit negative value a 64-bit
negative value.
For example:
bpf assembly excerpt of an inlined helper calling a kernel function and
checking for a specific error:
; err = bpf_map_update_elem(&mymap, &key, &val, BPF_NOEXIST);
...
46: call 0xffffffffe103291c ; htab_map_update_elem
; if (err && err != -EEXIST) {
4b: cmp $0xffffffffffffffef,%rax ; cmp -EEXIST,%rax
kernel function assembly excerpt of return value from
`htab_map_update_elem` returning 32-bit int:
movl $0xffffffef, %r9d
...
movl %r9d, %eax
...results in the comparison:
cmp $0xffffffffffffffef, $0x00000000ffffffef
Fixes: bdb7b79b4ce8 ("bpf: Switch most helper return values from 32-bit int to 64-bit long")
Tested-by: Eduard Zingerman <eddyz87@gmail.com>
Signed-off-by: JP Kobryn <inwardvessel@gmail.com>
Link: https://lore.kernel.org/r/20230322194754.185781-3-inwardvessel@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-03-23 03:47:54 +08:00
|
|
|
static long stack_map_update_elem(struct bpf_map *map, void *key, void *value,
|
|
|
|
|
u64 map_flags)
|
2016-02-18 11:58:58 +08:00
|
|
|
{
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Called from syscall or from eBPF program */
|
bpf: return long from bpf_map_ops funcs
This patch changes the return types of bpf_map_ops functions to long, where
previously int was returned. Using long allows for bpf programs to maintain
the sign bit in the absence of sign extension during situations where
inlined bpf helper funcs make calls to the bpf_map_ops funcs and a negative
error is returned.
The definitions of the helper funcs are generated from comments in the bpf
uapi header at `include/uapi/linux/bpf.h`. The return type of these
helpers was previously changed from int to long in commit bdb7b79b4ce8. For
any case where one of the map helpers call the bpf_map_ops funcs that are
still returning 32-bit int, a compiler might not include sign extension
instructions to properly convert the 32-bit negative value a 64-bit
negative value.
For example:
bpf assembly excerpt of an inlined helper calling a kernel function and
checking for a specific error:
; err = bpf_map_update_elem(&mymap, &key, &val, BPF_NOEXIST);
...
46: call 0xffffffffe103291c ; htab_map_update_elem
; if (err && err != -EEXIST) {
4b: cmp $0xffffffffffffffef,%rax ; cmp -EEXIST,%rax
kernel function assembly excerpt of return value from
`htab_map_update_elem` returning 32-bit int:
movl $0xffffffef, %r9d
...
movl %r9d, %eax
...results in the comparison:
cmp $0xffffffffffffffef, $0x00000000ffffffef
Fixes: bdb7b79b4ce8 ("bpf: Switch most helper return values from 32-bit int to 64-bit long")
Tested-by: Eduard Zingerman <eddyz87@gmail.com>
Signed-off-by: JP Kobryn <inwardvessel@gmail.com>
Link: https://lore.kernel.org/r/20230322194754.185781-3-inwardvessel@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-03-23 03:47:54 +08:00
|
|
|
static long stack_map_delete_elem(struct bpf_map *map, void *key)
|
2016-02-18 11:58:58 +08:00
|
|
|
{
|
|
|
|
|
struct bpf_stack_map *smap = container_of(map, struct bpf_stack_map, map);
|
|
|
|
|
struct stack_map_bucket *old_bucket;
|
|
|
|
|
u32 id = *(u32 *)key;
|
|
|
|
|
|
|
|
|
|
if (unlikely(id >= smap->n_buckets))
|
|
|
|
|
return -E2BIG;
|
|
|
|
|
|
|
|
|
|
old_bucket = xchg(&smap->buckets[id], NULL);
|
|
|
|
|
if (old_bucket) {
|
2016-03-08 13:57:17 +08:00
|
|
|
pcpu_freelist_push(&smap->freelist, &old_bucket->fnode);
|
2016-02-18 11:58:58 +08:00
|
|
|
return 0;
|
|
|
|
|
} else {
|
|
|
|
|
return -ENOENT;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Called when map->refcnt goes to zero, either from workqueue or from syscall */
|
|
|
|
|
static void stack_map_free(struct bpf_map *map)
|
|
|
|
|
{
|
|
|
|
|
struct bpf_stack_map *smap = container_of(map, struct bpf_stack_map, map);
|
|
|
|
|
|
bpf: don't trigger OOM killer under pressure with map alloc
This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
that are to be used for map allocations. Using kmalloc() for very large
allocations can cause excessive work within the page allocator, so i) fall
back earlier to vmalloc() when the attempt is considered costly anyway,
and even more importantly ii) don't trigger OOM killer with any of the
allocators.
Since this is based on a user space request, for example, when creating
maps with element pre-allocation, we really want such requests to fail
instead of killing other user space processes.
Also, don't spam the kernel log with warnings should any of the allocations
fail under pressure. Given that, we can make backend selection in
bpf_map_area_alloc() generic, and convert all maps over to use this API
for spots with potentially large allocation requests.
Note, replacing the one kmalloc_array() is fine as overflow checks happen
earlier in htab_map_alloc(), since it must also protect the multiplication
for vmalloc() should kmalloc_array() fail.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-18 22:14:17 +08:00
|
|
|
bpf_map_area_free(smap->elems);
|
2016-03-08 13:57:17 +08:00
|
|
|
pcpu_freelist_destroy(&smap->freelist);
|
bpf: don't trigger OOM killer under pressure with map alloc
This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
that are to be used for map allocations. Using kmalloc() for very large
allocations can cause excessive work within the page allocator, so i) fall
back earlier to vmalloc() when the attempt is considered costly anyway,
and even more importantly ii) don't trigger OOM killer with any of the
allocators.
Since this is based on a user space request, for example, when creating
maps with element pre-allocation, we really want such requests to fail
instead of killing other user space processes.
Also, don't spam the kernel log with warnings should any of the allocations
fail under pressure. Given that, we can make backend selection in
bpf_map_area_alloc() generic, and convert all maps over to use this API
for spots with potentially large allocation requests.
Note, replacing the one kmalloc_array() is fine as overflow checks happen
earlier in htab_map_alloc(), since it must also protect the multiplication
for vmalloc() should kmalloc_array() fail.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-18 22:14:17 +08:00
|
|
|
bpf_map_area_free(smap);
|
2016-02-18 11:58:58 +08:00
|
|
|
put_callchain_buffers();
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-05 20:46:02 +08:00
|
|
|
static u64 stack_map_mem_usage(const struct bpf_map *map)
|
|
|
|
|
{
|
|
|
|
|
struct bpf_stack_map *smap = container_of(map, struct bpf_stack_map, map);
|
|
|
|
|
u64 value_size = map->value_size;
|
|
|
|
|
u64 n_buckets = smap->n_buckets;
|
|
|
|
|
u64 enties = map->max_entries;
|
|
|
|
|
u64 usage = sizeof(*smap);
|
|
|
|
|
|
|
|
|
|
usage += n_buckets * sizeof(struct stack_map_bucket *);
|
|
|
|
|
usage += enties * (sizeof(struct stack_map_bucket) + value_size);
|
|
|
|
|
return usage;
|
|
|
|
|
}
|
|
|
|
|
|
2022-04-25 21:32:47 +08:00
|
|
|
BTF_ID_LIST_SINGLE(stack_trace_map_btf_ids, struct, bpf_stack_map)
|
2018-10-18 21:16:09 +08:00
|
|
|
const struct bpf_map_ops stack_trace_map_ops = {
|
2020-08-28 09:18:06 +08:00
|
|
|
.map_meta_equal = bpf_map_meta_equal,
|
2016-02-18 11:58:58 +08:00
|
|
|
.map_alloc = stack_map_alloc,
|
|
|
|
|
.map_free = stack_map_free,
|
|
|
|
|
.map_get_next_key = stack_map_get_next_key,
|
|
|
|
|
.map_lookup_elem = stack_map_lookup_elem,
|
|
|
|
|
.map_update_elem = stack_map_update_elem,
|
|
|
|
|
.map_delete_elem = stack_map_delete_elem,
|
2018-08-12 07:59:17 +08:00
|
|
|
.map_check_btf = map_check_no_btf,
|
2023-03-05 20:46:02 +08:00
|
|
|
.map_mem_usage = stack_map_mem_usage,
|
2022-04-25 21:32:47 +08:00
|
|
|
.map_btf_id = &stack_trace_map_btf_ids[0],
|
2016-02-18 11:58:58 +08:00
|
|
|
};
|
