05 Jun, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of version 2 of the gnu general public license as
    published by the free software foundation this program is
    distributed in the hope that it will be useful but without any
    warranty without even the implied warranty of merchantability or
    fitness for a particular purpose see the gnu general public license
    for more details

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 64 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Alexios Zavras
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190529141901.894819585@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

24 Mar, 2018

1 commit

  • We use print_bpf_insn in user space (bpftool and soon perf),
    so it'd be nice to keep it generic and strip it off the kernel
    struct bpf_verifier_env argument.

    This argument can be safely removed, because its users can
    use the struct bpf_insn_cbs::private_data to pass it.

    By changing the argument type we can no longer have clean
    'verbose' alias to 'bpf_verifier_log_write' in verifier.c.
    Instead we're adding the 'verbose' cb_print callback and
    removing the alias.

    This way we have new cb_print callback in place, and all
    the 'verbose(env, ...) calls in verifier.c will cleanly
    cast to 'verbose(void *, ...)' so no other change is
    needed.

    Signed-off-by: Jiri Olsa
    Signed-off-by: Daniel Borkmann

    Jiri Olsa
     

17 Jan, 2018

1 commit


21 Dec, 2017

1 commit

  • Currently a dump of an xlated prog (post verifier stage) doesn't
    correlate used helpers as well as maps. The prog info lists
    involved map ids, however there's no correlation of where in the
    program they are used as of today. Likewise, bpftool does not
    correlate helper calls with the target functions.

    The latter can be done w/o any kernel changes through kallsyms,
    and also has the advantage that this works with inlined helpers
    and BPF calls.

    Example, via interpreter:

    # tc filter show dev foo ingress
    filter protocol all pref 49152 bpf chain 0
    filter protocol all pref 49152 bpf chain 0 handle 0x1 foo.o:[ingress] \
    direct-action not_in_hw id 1 tag c74773051b364165
    Acked-by: Alexei Starovoitov
    Signed-off-by: Alexei Starovoitov

    Daniel Borkmann
     

11 Oct, 2017

1 commit