On Tue, Sep 3, 2019 at 11:20 PM Masahiro Yamada
wrote:
>
> On Wed, Sep 4, 2019 at 3:00 PM Stephen Rothwell wrote:
> >
> > Hi all,
> >
> > After merging the net-next tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > scripts/link-vmlinux.sh: 74: Bad substitution
On Thu, Sep 5, 2019 at 7:53 PM Masahiro Yamada
wrote:
>
> On Fri, Sep 6, 2019 at 4:26 AM Andrii Nakryiko
> wrote:
> >
> > On Tue, Sep 3, 2019 at 11:20 PM Masahiro Yamada
> > wrote:
> > >
> > > On Wed, Sep 4, 2019 at 3:00 PM Stephen R
On Wed, Jul 29, 2020 at 6:38 PM Roman Gushchin wrote:
>
> On Mon, Jul 27, 2020 at 10:59:33PM -0700, Andrii Nakryiko wrote:
> > On Mon, Jul 27, 2020 at 4:15 PM Roman Gushchin wrote:
> > >
> > > On Mon, Jul 27, 2020 at 03:05:11PM -0700, Andrii Nakryiko wrote:
> &g
On Thu, Jul 30, 2020 at 11:18 PM Jianlin Lv wrote:
>
> Clang compiler version: 12.0.0
> The following warning appears during the selftests/bpf compilation:
>
> prog_tests/send_signal.c:51:3: warning: ignoring return value of ‘write’,
> declared with attribute warn_unused_result [-Wunused-result]
On Tue, Jun 23, 2020 at 11:46 PM Li Xinhai wrote:
>
> - information of machine
> Linux localhost.localdomain 4.18.0-193.6.3.el8_2.x86_64 #1 SMP Wed Jun 10
> 11:09:32 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
>
> - configurations
> make defconfig
> make kvmconfig
>
> - failed logs on v5.6
> ```
>
On Mon, Jul 20, 2020 at 1:28 PM Hao Luo wrote:
>
> >
> > This should ideally look like a real global variable extern:
> >
> > extern const struct rq runqueues __ksym;
> >
> >
> > But that's the case for non-per-cpu variables. You didn't seem to
> > address per-CPU variables in this patch set. How
On Mon, Jul 27, 2020 at 12:21 PM Roman Gushchin wrote:
>
> As bpf is not using memlock rlimit for memory accounting anymore,
> let's remove the related code from libbpf.
>
> Bpf operations can't fail because of exceeding the limit anymore.
>
They can't in the newest kernel, but libbpf will keep
On Mon, Jul 27, 2020 at 11:58 AM Randy Dunlap wrote:
>
> On 7/27/20 6:23 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20200724:
> >
>
> on i386:
> when CONFIG_XPS is not set/enabled:
>
> ld: kernel/bpf/syscall.o: in function `__do_sys_bpf':
> syscall.c:(.text+0x4482): undefined
er, so to simplify the code make it return NULL
> in the first case. This allows to drop a couple of lines in
> ringbuf_map_alloc() and also makes it look similar to other memory
> allocating function like kmalloc().
>
> Signed-off-by: Roman Gushchin
> ---
LGTM.
Acked-by: Andrii Nak
On Mon, Jul 27, 2020 at 10:47 PM Song Liu wrote:
>
> On Mon, Jul 27, 2020 at 12:26 PM Roman Gushchin wrote:
> >
> > Remove rlimit-based accounting infrastructure code, which is not used
> > anymore.
> >
> > Signed-off-by: Roman Gushchin
> [...]
> >
> > static void bpf_map_put_uref(struct
On Mon, Jul 27, 2020 at 4:15 PM Roman Gushchin wrote:
>
> On Mon, Jul 27, 2020 at 03:05:11PM -0700, Andrii Nakryiko wrote:
> > On Mon, Jul 27, 2020 at 12:21 PM Roman Gushchin wrote:
> > >
> > > As bpf is not using memlock rlimit for memory accounting anymore,
>
On Mon, Jul 27, 2020 at 12:21 PM Roman Gushchin wrote:
>
> Since bpf stopped using memlock rlimit to limit the memory usage,
> there is no more reason for bpftool to alter its own limits.
>
> Signed-off-by: Roman Gushchin
> ---
This can't be removed either, due to old kernel support. We
> 1 file changed, 16 deletions(-)
>
This can go, I suppose, we still have a runqslower variant in BCC with
this logic, to show an example on what/how to do this for kernels
without this patch set applied.
Acked-by: Andrii Nakryiko
> diff --git a/tools/bpf/runqslower/runqslower.c
> b/
On Mon, Jul 27, 2020 at 12:21 PM Roman Gushchin wrote:
>
> Since bpf is not using memlock rlimit for memory accounting,
> there are no more reasons to bump the limit.
>
> Signed-off-by: Roman Gushchin
> ---
Similarly for bench, it's a tool that's not coupled with the latest
kernel version, it
On Mon, Jul 27, 2020 at 12:21 PM Roman Gushchin wrote:
>
> Since bpf stopped using memlock rlimit to limit the memory usage,
> there is no more reason for perf to alter its own limit.
>
> Signed-off-by: Roman Gushchin
> ---
Cc'd Armaldo, but I'm guessing it's a similar situation that latest
On Mon, Jul 27, 2020 at 12:25 PM Roman Gushchin wrote:
>
> As rlimit-based memory accounting is not used by bpf anymore,
> there are no more reasons to play with memlock rlimit.
>
> Delete bpf_rlimit.h which contained a code to bump the limit.
>
> Signed-off-by: Roman Gushchin
> ---
We run
On Mon, Jul 27, 2020 at 11:11 PM Song Liu wrote:
>
>
>
> > On Jul 27, 2020, at 11:06 PM, Andrii Nakryiko
> > wrote:
> >
> > On Mon, Jul 27, 2020 at 12:25 PM Roman Gushchin wrote:
> >>
> >> As rlimit-based memory accounting is not used by
On Mon, Jul 27, 2020 at 11:01 PM Randy Dunlap wrote:
>
> On 7/27/20 10:48 PM, Andrii Nakryiko wrote:
> > On Mon, Jul 27, 2020 at 11:58 AM Randy Dunlap wrote:
> >>
> >> On 7/27/20 6:23 AM, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >&
On Tue, Jul 28, 2020 at 12:09 PM Roman Gushchin wrote:
>
> On Mon, Jul 27, 2020 at 11:06:42PM -0700, Song Liu wrote:
> > On Mon, Jul 27, 2020 at 10:58 PM Andrii Nakryiko
> > wrote:
> > >
> > > On Mon, Jul 27, 2020 at 10:47 PM Song Liu wrote:
> > &g
On Tue, Jul 14, 2020 at 11:08 PM Song Liu wrote:
>
> Calling get_perf_callchain() on perf_events from PEBS entries may cause
> unwinder errors. To fix this issue, the callchain is fetched early. Such
> perf_events are marked with __PERF_SAMPLE_CALLCHAIN_EARLY.
>
> Similarly, calling
bpf/progs/perf_event_stackmap.c
>
Just few simplification suggestions, but overall looks good, so please add:
Acked-by: Andrii Nakryiko
[...]
> +
> +void test_perf_event_stackmap(void)
> +{
> + struct perf_event_attr attr = {
> + /* .type = PERF_TYPE_
On Fri, Jul 17, 2020 at 12:24 AM Ian Rogers wrote:
>
> The non-builtin route for offsetof has a dependency on size_t from
> stdlib.h/stdint.h that is undeclared and may break targets.
> The offsetof macro in bpf_helpers may disable the same macro in other
> headers that have a #ifdef offsetof
On Wed, Jul 15, 2020 at 2:45 PM Hao Luo wrote:
>
> Previous commits:
>
> commit 1c0c7074fefd ("libbpf: Add support for extracting kernel symbol
> addresses")
> commit 2e33efe32e01 ("libbpf: Generalize libbpf externs support")
>
> have introduced a new type of extern variable ksyms to access
On Wed, Jul 15, 2020 at 2:46 PM Hao Luo wrote:
>
> Extend ksyms.c selftest to make sure BTF enables direct loads of ksyms.
>
> Note that test is done against the kernel btf extended with kernel VARs.
>
> Signed-off-by: Hao Luo
> ---
> tools/testing/selftests/bpf/prog_tests/ksyms.c | 2 ++
>
#ifdef offsetof guard. Rather than add additional
> dependencies improve the offsetof macro declared here to use the
> builtin that is available since llvm 3.7 (the first with a BPF backend).
>
> Signed-off-by: Ian Rogers
> ---
Acked-by: Andrii Nakryiko
> tools/lib/bpf/bpf_help
On Tue, Jul 21, 2020 at 10:44 PM Ian Rogers wrote:
>
> When bpftool dumps types and enum members into a header file for
> inclusion the names match those in the original source. If the same
> header file needs to be included in the original source and the bpf
> program, the names of structs,
you please re-submit with [PATCH bpf-next]
subject prefix, as it's intended for bpf-next tree. With that:
Acked-by: Andrii Nakryiko
> tools/lib/bpf/libbpf.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
On Thu, Jun 20, 2019 at 1:08 AM Naresh Kamboju
wrote:
>
> selftests: bpf test_libbpf.sh failed running Linux -next kernel
> 20190618 and 20190619.
>
> Here is the log from x86_64,
> # selftests bpf test_libbpf.sh
> bpf: test_libbpf.sh_ #
> # [0] libbpf BTF is required, but is missing or
)
On Fri, Jun 21, 2019 at 9:11 AM Stanislav Fomichev wrote:
>
> On 06/21, kernel test robot wrote:
> > FYI, we noticed the following commit (built with gcc-7):
> >
> > commit: 69d96519dbf0bfa1868dc8597d4b9b2cdeb009d7 ("selftests/bpf: convert
> > socket_cookie test to sk storage")
> >
8fe7a66f93f8 CR3: 000139d1c006 CR4:
> 00360ef0
> [ 16.396876] DR0: DR1: DR2:
>
> [ 16.397557] DR3: DR6: fffe0ff0 DR7:
> 0400
> [ 16.398246] Kernel panic - not syncing:
On Thu, Jun 27, 2019 at 8:50 AM Stanislav Fomichev wrote:
>
> On 06/27, kernel test robot wrote:
> > FYI, we noticed the following commit (built with gcc-7):
> >
> > commit: cd17d77705780e2270937fb3cbd2b985adab3edc ("bpf/tools: sync bpf.h")
> >
On Thu, Jun 27, 2019 at 10:29 AM Stanislav Fomichev wrote:
>
> On 06/27, Stanislav Fomichev wrote:
> > On 06/27, kernel test robot wrote:
> > > FYI, we noticed the following commit (built with gcc-7):
> > >
> > > commit: cd17d77705780e2270937fb3cbd2b985adab3edc ("bpf/tools: sync bpf.h")
> > >
On Thu, Jun 27, 2019 at 7:38 PM Stanislav Fomichev wrote:
>
> On 06/27, Andrii Nakryiko wrote:
> > On Thu, Jun 27, 2019 at 10:29 AM Stanislav Fomichev
> > wrote:
> > >
> > > On 06/27, Stanislav Fomichev wrote:
> > > > On 06/27, kernel test robo
"value": {
> "error": "Operation not supported"
> }
> },{
> "key": ["0x0a","0x41","0x00","0x02","0x1f","0x78","0x00","0x01"
>
On Thu, Jun 6, 2019 at 1:17 PM Matt Mullins wrote:
>
> BPF_PROG_TYPE_RAW_TRACEPOINTs can be executed nested on the same CPU, as
> they do not increment bpf_prog_active while executing.
>
> This enables three levels of nesting, to support
> - a kprobe or raw tp or perf event,
> - another one
On Tue, Jun 11, 2019 at 7:05 AM Gustavo A. R. Silva
wrote:
>
> In preparation to enabling -Wimplicit-fallthrough, this patch silences
> the following warning:
Your patch doesn't apply cleanly to neither bpf nor bpf-next tree.
Could you please rebase and re-submit? Please also include which tree
On Tue, Jun 11, 2019 at 10:41 AM Gustavo A. R. Silva
wrote:
>
>
>
> On 6/11/19 12:27 PM, Gustavo A. R. Silva wrote:
> >
> >
> > On 6/11/19 12:22 PM, Andrii Nakryiko wrote:
> >> On Tue, Jun 11, 2019 at 7:05 AM Gustavo A. R. Silva
> >> wrote:
&
> - another one of the above that irq context happens to call, and
> - another one in nmi context
> (at most one of which may be a kprobe or perf event).
>
> Fixes: 20b9d7ac4852 ("bpf: avoid excessive stack usage for perf_sample_data")
> Signed-off-by: Matt Mullins
&
y: Michal Rostecki
> ---
Acked-by: Andrii Nakryiko
> samples/bpf/ibumad_kern.c | 18 ++
> 1 file changed, 6 insertions(+), 12 deletions(-)
>
efforts to enable
> -Wimplicit-fallthrough.
>
> [1] https://lore.kernel.org/patchwork/patch/1087056/
>
> Signed-off-by: Gustavo A. R. Silva
> ---
Acked-by: Andrii Nakryiko
> kernel/bpf/verifier.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kerne
efforts to enable
> -Wimplicit-fallthrough.
>
> [1] https://lore.kernel.org/patchwork/patch/1087056/
>
> Signed-off-by: Gustavo A. R. Silva
> ---
Acked-by: Andrii Nakryiko
> kernel/bpf/verifier.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kerne
On Mon, May 11, 2020 at 10:59 PM Alan Maguire wrote:
>
> tests verify we get > 0 return value from bpf_trace_print()
> using %pT format specifier with various modifiers/pointer
> values.
>
> Signed-off-by: Alan Maguire
> ---
There is no need to use perf buffer for returning results to
On Fri, May 15, 2020 at 9:51 AM Ian Rogers wrote:
>
> Remove #include of libbpf_internal.h that is unused.
> Discussed in this thread:
> https://lore.kernel.org/lkml/caef4bzzrmieds_8r8g4vaaewvjzpb4xylnpf0x2vny8otzk...@mail.gmail.com/
>
> Signed-off-by: Ian Rogers
> ---
Acke
On Fri, May 15, 2020 at 9:51 AM Ian Rogers wrote:
>
> Use a hashmap between a char* string and a double* value. While bpf's
> hashmap entries are size_t in size, we can't guarantee sizeof(size_t) >=
> sizeof(double). Avoid a memory allocation when gathering ids by making 0.0
> a special value
> 150 | for (bkt = 0; bkt < map->cap; bkt++)\
>
> Signed-off-by: Ian Rogers
> ---
Acked-by: Andrii Nakryiko
> tools/lib/bpf/hashmap.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/tools/lib/bpf/hashmap.c b/tools/lib/bp
>
> Signed-off-by: Ian Rogers
> ---
Given you want to make sure they stay 1 to 1, would just creating a
symlink work instead of copying the code?
Either way, I think hashmap is stable and not going to change
frequently, so whichever way is fine with me.
Acked-by: Andrii Nakryi
t; >
> > The hashmap change was originally part of an RFC:
> > https://lore.kernel.org/lkml/20200508053629.210324-1-irog...@google.com/
> >
> > v2. moves hashmap into tools/perf/util rather than libapi, to allow
> > hashmap's libbpf symbols to be visible when built sta
On Fri, May 8, 2020 at 12:21 AM Ian Rogers wrote:
>
> On Fri, May 8, 2020 at 12:12 AM Andrii Nakryiko
> wrote:
> >
> > On Thu, May 7, 2020 at 11:40 PM Ian Rogers wrote:
> > >
> > > If bits is 0, the case when the map is empty, then the >> is the
On Wed, May 6, 2020 at 1:54 PM Ian Rogers wrote:
>
> Don't include libbpf_internal.h as it is unused and has conflicting
> definitions, for example, with tools/perf/util/debug.h.
> Fix a non-glibc include path.
>
> Signed-off-by: Ian Rogers
> ---
> tools/lib/bpf/hashmap.h | 3 +--
> 1 file
On Wed, May 6, 2020 at 1:55 PM Ian Rogers wrote:
>
> hashmap_find_entry assumes that if buckets is NULL then there are no
> entries. NULL the buckets in clear to ensure this.
> Free hashmap entries and not just the bucket array.
>
> Signed-off-by: Ian Rogers
> ---
This is already fixed in
On Wed, May 6, 2020 at 2:47 PM Ian Rogers wrote:
>
> On Wed, May 6, 2020 at 2:33 PM Andrii Nakryiko
> wrote:
> >
> > On Wed, May 6, 2020 at 1:54 PM Ian Rogers wrote:
> > >
> > > Don't include libbpf_internal.h as it is unused and has conflicting
> >
On Thu, May 7, 2020 at 11:40 PM Ian Rogers wrote:
>
> If bits is 0, the case when the map is empty, then the >> is the size of
> the register which is undefined behavior - on x86 it is the same as a
> shift by 0. Fix by handling the 0 case explicitly.
>
> Signed-off-by: Ian Rogers
> ---
No
On Fri, May 8, 2020 at 8:39 AM Christoph Hellwig wrote:
>
> Use __anon_inode_getfd instead of opencoding the logic using
> get_unused_fd_flags + anon_inode_getfile. Also switch the
> bpf_link_new_file calling conventions to match __anon_inode_getfd.
>
> Signed-off-by: Christoph Hellwig
> ---
>
> create mode 100644 tools/testing/selftests/bpf/progs/bpf_iter_task_stack.c
>
> --
> 2.24.1
Thanks for working on this! This will enable a whole new set of tools
and applications.
Acked-by: Andrii Nakryiko
On Mon, Jul 13, 2020 at 5:43 PM Peilin Ye wrote:
>
> Prevent __btf_resolve_helper_id() from dereferencing `btf_vmlinux`
> as NULL. This patch fixes the following syzbot bug:
>
>
> https://syzkaller.appspot.com/bug?id=5edd146856fd513747c1992442732e5a0e9ba355
>
> Reported-by:
> Reported-by: syzbot+ee09bda7017345f1f...@syzkaller.appspotmail.com
> Signed-off-by: Peilin Ye
> ---
> Thank you for reviewing my patch! I am new to Linux kernel development; would
> the log message and errno be appropriate for this case?
I think it's good enough, thanks for the fix.
Ac
On Fri, Jul 3, 2020 at 7:47 AM Alan Maguire wrote:
>
> The bpf helper bpf_trace_printk() uses trace_printk() under the hood.
> This leads to an alarming warning message originating from trace
> buffer allocation which occurs the first time a program using
> bpf_trace_printk() is loaded.
>
> We
On Fri, Jul 3, 2020 at 7:45 AM Alan Maguire wrote:
>
> Simple selftest that verifies bpf_trace_printk() returns a sensible
> value and tracing messages appear.
>
> Signed-off-by: Alan Maguire
> ---
> .../selftests/bpf/prog_tests/trace_printk.c| 71
> ++
>
est_vmlinux:PASS:fentry 0 nsec
>
> Signed-off-by: Hao Luo
> ---
Took me a bit of jumping around to find how it is related to nanosleep
call :) But seems like it's unconditionally called, so should be fine.
Acked-by: Andrii Nakryiko
> tools/testing/selftests/bpf/progs/test_vmlinux.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
[...]
On Wed, Jul 8, 2020 at 11:16 AM Jesper Dangaard Brouer
wrote:
>
> On Tue, 7 Jul 2020 00:23:48 -0700
> Andrii Nakryiko wrote:
>
> > On Tue, Jul 7, 2020 at 12:12 AM Jesper Dangaard Brouer
> > wrote:
> > >
> > > This patchset makes it easier to use test
On Mon, Jul 6, 2020 at 10:00 AM Jesper Dangaard Brouer
wrote:
>
> There are a number of places in test_progs that use minus-1 as the argument
> to exit(). This improper use as a process exit status is masked to be a
> number between 0 and 255 as defined in man exit(3).
nit: I wouldn't call it
> Jesper Dangaard Brouer (2):
> selftests/bpf: test_progs use another shell exit on non-actions
> selftests/bpf: test_progs avoid minus shell exit codes
>
>
> tools/testing/selftests/bpf/test_progs.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletion
On Fri, Jul 10, 2020 at 2:21 AM Wenbo Zhang wrote:
>
> The `BPF_LOG_BUF_SIZE`'s value is `UINT32_MAX >> 8`, so define an array
> with it on stack caused an overflow.
>
> Signed-off-by: Wenbo Zhang
> ---
Acked-by: Andrii Nakryiko
> samples/bpf/fds_example.c |
On Fri, Jul 10, 2020 at 7:25 AM Alan Maguire wrote:
>
> Simple selftests that verifies bpf_trace_printk() returns a sensible
> value and tracing messages appear.
>
> Signed-off-by: Alan Maguire
> ---
see pedantic note below, but I don't think that's an issue in practice
work was started by Steven (see Link) and finished by Alan; added
> Steven's Signed-off-by with his permission.
>
> Link: https://lore.kernel.org/r/20200628194334.6238b...@oasis.local.home
> Signed-off-by: Steven Rostedt (VMware)
> Signed-off-by: Alan Maguire
> ---
LGTM.
Acked-by: Andrii Na
On Fri, Jul 10, 2020 at 6:30 PM Song Liu wrote:
>
> Calling get_perf_callchain() on perf_events from PEBS entries may cause
> unwinder errors. To fix this issue, the callchain is fetched early. Such
> perf_events are marked with __PERF_SAMPLE_CALLCHAIN_EARLY.
>
> Similarly, calling
On Fri, Jul 10, 2020 at 11:28 PM Song Liu wrote:
>
>
>
> > On Jul 10, 2020, at 8:53 PM, Andrii Nakryiko
> > wrote:
> >
> > On Fri, Jul 10, 2020 at 6:30 PM Song Liu wrote:
> >>
> >> Calling get_perf_callchain() on perf_events from PEBS entrie
On Fri, Jun 26, 2020 at 5:10 AM Peter Zijlstra wrote:
>
> On Thu, Jun 25, 2020 at 05:13:29PM -0700, Song Liu wrote:
> > This would be used by bpf stack mapo.
>
> Would it make sense to sanitize the API a little before exposing it?
>
> diff --git a/kernel/events/callchain.c
sk_struct pointer, just pid, so would be nice
to not artificially restrict such cases by having extra helper.
Acked-by: Andrii Nakryiko
> include/linux/bpf.h| 1 +
> include/uapi/linux/bpf.h | 35 ++-
> kernel/bpf/stackmap.c | 79 +++
On Thu, Jun 25, 2020 at 5:15 PM Song Liu wrote:
>
> The new test is similar to other bpf_iter tests.
>
> Signed-off-by: Song Liu
> ---
> .../selftests/bpf/prog_tests/bpf_iter.c | 17 ++
> .../selftests/bpf/progs/bpf_iter_task_stack.c | 60 +++
> 2 files changed, 77
On Fri, Jun 26, 2020 at 1:17 PM Andrii Nakryiko
wrote:
>
> On Thu, Jun 25, 2020 at 5:14 PM Song Liu wrote:
> >
> > Introduce helper bpf_get_task_stack(), which dumps stack trace of given
> > task. This is different to bpf_get_stack(), which gets stack track of
> > c
On Fri, Jun 26, 2020 at 3:45 PM Song Liu wrote:
>
>
>
> > On Jun 26, 2020, at 1:17 PM, Andrii Nakryiko
> > wrote:
> >
> > On Thu, Jun 25, 2020 at 5:14 PM Song Liu wrote:
> >>
> >> Introduce helper bpf_get_task_stack(), which dump
On Fri, Jun 26, 2020 at 4:05 PM Song Liu wrote:
>
>
>
> > On Jun 26, 2020, at 1:21 PM, Andrii Nakryiko
> > wrote:
> >
> > On Thu, Jun 25, 2020 at 5:15 PM Song Liu wrote:
> >>
> >> The new test is similar to other bpf_iter tests.
> >&g
On Fri, Jun 26, 2020 at 4:47 PM Song Liu wrote:
>
>
>
> > On Jun 26, 2020, at 3:51 PM, Andrii Nakryiko
> > wrote:
> >
> > On Fri, Jun 26, 2020 at 3:45 PM Song Liu wrote:
> >>
> >>
> >>
> >>> On Jun 26, 2020, at 1:17 PM, An
On Fri, Jun 26, 2020 at 5:26 PM Song Liu wrote:
>
> Sanitize and expose get/put_callchain_entry(). This would be used by bpf
> stack map.
>
> Suggested-by: Peter Zijlstra
> Signed-off-by: Song Liu
> ---
Acked-by: Andrii Nakryiko
> include/linux/perf_event.h
gt; using stack_trace_save_tsk() is that stack_trace_save_tsk() dumps the
> stack trace to unsigned long array. For 32-bit systems, we need to
> translate it to u64 array.
>
> Acked-by: Andrii Nakryiko
> Signed-off-by: Song Liu
> ---
> include/linux/bpf.h| 1 +
> include/uapi
On Thu, May 21, 2020 at 5:54 AM Ferenc Fejes wrote:
>
> This option makes possible to programatically bind sockets to netdevices.
> With the help of this option sockets of VRF unaware applications
> could be distributed between multiple VRFs with eBPF sock_ops program.
> This let the applications
per
> shared by the proper kernel and user probe helpers. This slightly
> changes behavior as the compat probe on a user address doesn't check
> the lockdown flags, just as the pure user probes do.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good, thanks.
Acked-by: Andrii Nakryiko
On Thu, May 21, 2020 at 8:25 AM Christoph Hellwig wrote:
>
> Split out a helper to do the fault free access to the string pointer
> to get it out of a crazy indentation level.
>
> Signed-off-by: Christoph Hellwig
> ---
LGTM.
Acked-by: Andrii Nakryiko
> kernel/t
On Thu, May 21, 2020 at 8:24 AM Christoph Hellwig wrote:
>
> User the proper helper for kernel or userspace addresses based on
> TASK_SIZE instead of the dangerous strncpy_from_unsafe function.
>
> Signed-off-by: Christoph Hellwig
> ---
Acked-by: Andrii Nakryiko
> ker
On Tue, Jun 16, 2020 at 8:54 AM KP Singh wrote:
>
> On 01-Jun 13:29, Andrii Nakryiko wrote:
> > On Tue, May 26, 2020 at 9:34 AM KP Singh wrote:
> > >
> > > From: KP Singh
> > >
> > > inode_local_storage:
> > >
> > > * Hook to t
_T__, which is more directly what
hash_bits work with, but I don't think it matters for any reasonable
system in use :)
So yeah,
Acked-by: Andrii Nakryiko
Are you going to do this change for libbpf's variant, or should I
submit a separate patch?
>
> static inline size_t hash_bits(size_t h, int bits)
On Tue, Jun 23, 2020 at 5:12 AM Alan Maguire wrote:
>
> tests verify we get 0 return value from bpf_trace_print()
> using %pT format specifier with various modifiers/pointer
> values.
>
> Signed-off-by: Alan Maguire
> ---
Acked-by: Andrii Nakryiko
> .../
On Tue, Jun 23, 2020 at 1:43 AM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in a pr_warn message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
Acked-by: Andrii Nakryiko
> tools/lib/bpf/libbpf.c | 2 +-
> 1 file changed,
: 8 bytes */
> };
> #
>
> Then looking if PATH_MAX leaves some signature in the tests:
>
> │ if (augmented_args->filename.size <
> sizeof(augmented_args->filename.value)) {
>▒
>│ cmp
On Mon, Oct 19, 2020 at 10:38 AM wrote:
>
> From: Tom Rix
>
> A break is not needed if it is preceded by a return
>
> Signed-off-by: Tom Rix
> ---
Probably refactoring left over, looks good:
Acked-by: Andrii Nakryiko
> kernel/bpf/syscall.c | 1 -
> 1 file chan
On Mon, Dec 7, 2020 at 3:00 AM Brendan Jackman wrote:
>
> On Fri, Dec 04, 2020 at 11:00:24AM -0800, Andrii Nakryiko wrote:
> > On Fri, Dec 4, 2020 at 1:41 AM Brendan Jackman wrote:
> > >
> > > On Thu, Dec 03, 2020 at 01:01:27PM -0800, Andrii Nakryiko wrote:
> >
On Fri, Dec 4, 2020 at 4:37 PM Daniel Borkmann wrote:
>
> On 12/3/20 4:26 AM, Roman Gushchin wrote:
> > On Wed, Dec 02, 2020 at 06:54:46PM -0800, Alexei Starovoitov wrote:
> >> On Tue, Dec 1, 2020 at 1:59 PM Roman Gushchin wrote:
> >>>
> >>> 5) Cryptic -EPERM is returned on exceeding the limit.
On Sat, Dec 5, 2020 at 4:44 PM Alan Maguire wrote:
>
>
> On Sat, 5 Dec 2020, Yonghong Song wrote:
>
> >
> >
> > __builtin_btf_type_id() is really only supported in llvm12
> > and 64bit return value support is pushed to llvm12 trunk
> > a while back. The builtin is introduced in llvm11 but has a
>
On Tue, Dec 8, 2020 at 9:04 AM Brendan Jackman wrote:
>
> On Mon, Dec 07, 2020 at 06:19:12PM -0800, Andrii Nakryiko wrote:
> > On Mon, Dec 7, 2020 at 3:00 AM Brendan Jackman wrote:
> > >
> > > On Fri, Dec 04, 2020 at 11:00:24AM -0800, Andrii Nakryiko wrote:
> >
On Mon, Jan 11, 2021 at 8:06 AM Gilad Reti wrote:
>
> On Mon, Jan 11, 2021, 17:55 Daniel Borkmann wrote:
> >
> > Hello Gilad,
> >
> > On 1/11/21 4:31 PM, giladreti wrote:
> > > Added support for pointer to mem register spilling, to allow the verifier
> > > to track pointer to valid memory
On Mon, Jan 11, 2021 at 12:00 PM Nathan Chancellor
wrote:
>
> On Tue, Jan 12, 2021 at 04:50:50AM +0900, Masahiro Yamada wrote:
> > On Tue, Jan 12, 2021 at 4:34 AM Nathan Chancellor
> > wrote:
> > >
> > > On Tue, Jan 12, 2021 at 04:19:01AM +0900, Masahiro Yamada wrote:
> > > > On Tue, Jan 12,
On Fri, Jan 8, 2021 at 3:30 PM Song Liu wrote:
>
> Task local storage is enabled for tracing programs. Add a test for it
> without CONFIG_BPF_LSM.
>
> Signed-off-by: Song Liu
> ---
> .../bpf/prog_tests/test_task_local_storage.c | 34 +
>
On Mon, Jan 11, 2021 at 7:24 PM Yonghong Song wrote:
>
>
>
> On 1/11/21 2:54 PM, Song Liu wrote:
> >
> >
> >> On Jan 11, 2021, at 9:49 AM, Yonghong Song wrote:
> >>
> >>
> >>
> >> On 1/8/21 3:19 PM, Song Liu wrote:
> >>> Replace hashtab with task local storage in runqslower. This improves the
>
On Mon, Jan 11, 2021 at 10:20 AM Qais Yousef wrote:
>
> Reuse module_attach infrastructure to add a new bare tracepoint to check
> we can attach to it as a raw tracepoint.
>
> Signed-off-by: Qais Yousef
> ---
>
> Andrii
>
> I was getting the error below when I was trying to run the test.
> I had
On Mon, Jan 11, 2021 at 9:34 AM Alan Maguire wrote:
>
> libbpf already supports a "dumper" API for dumping type information,
> but there is currently no support for dumping typed _data_ via libbpf.
> However this functionality does exist in the kernel, in part to
> facilitate the
On Tue, Jan 12, 2021 at 4:39 AM Brendan Jackman wrote:
>
> The error message here is misleading, the argument will be rejected
> unless it is a known constant.
>
> Signed-off-by: Brendan Jackman
> ---
LGTM.
Acked-by: Andrii Nakryiko
> kernel/bpf/verifier.c | 2 +-
On Fri, Jan 8, 2021 at 3:12 AM Christopher William Snowhill
wrote:
>
> There appears to be a regression with the filesystem NLS modules. I cannot
> load any of them. They all produce:
>
> modprobe: ERROR: could not insert 'nls_cp437': Invalid argument
>
> The system journal reports:
>
> Jan 08
On Thu, Jan 7, 2021 at 6:08 PM 彭浩(Richard) wrote:
>
> struct bpf_object *obj is not used in bpf_object__probe_loading, so we
> can remove it.
>
> Signed-off-by: Peng Hao
> ---
It causes no harm, no performance cost, and no maintenance issues. I
consider eventually allowing to have a
On Thu, Feb 4, 2021 at 11:27 AM Song Liu wrote:
>
> On Thu, Feb 4, 2021 at 3:42 AM Tiezhu Yang wrote:
> >
> > The program is made in a way that everytime an execve syscall
> > is executed it prints Hello, BPF World!
> >
> > This is inspired and based on the code example for the book
> > Linux
301 - 400 of 669 matches
Mail list logo
