On Wed, May 22, 2019 at 2:25 AM Björn Töpel wrote:
>
> Add three tests to test_verifier/basic_instr that make sure that the
> high 32-bits of the destination register is cleared after an ALU32
> and/or/xor.
>
> Signed-off-by: Björn Töpel
I think the patch intends for bpf-next, right? The patch i
On Wed, May 22, 2019 at 1:46 PM Björn Töpel wrote:
>
> On Wed, 22 May 2019 at 20:13, Y Song wrote:
> >
> > On Wed, May 22, 2019 at 2:25 AM Björn Töpel wrote:
> > >
> > > Add three tests to test_verifier/basic_instr that make sure that the
> > >
On Thu, May 23, 2019 at 12:26 AM Daniel T. Lee wrote:
>
> This commit fixes style problem in samples/bpf/bpf_load.c
>
> Styles that have been changed are:
> - Magic string use of 'DEBUGFS'
> - Useless zero initialization of a global variable
> - Minor style fix with whitespace
>
> Signed-off-by
On Fri, May 24, 2019 at 3:29 PM Stanislav Fomichev wrote:
>
> Right now test_tunnel.sh always exits with success even if some
> of the subtests fail. Since the output is very verbose, it's
> hard to spot the issues with subtests. Let's fail the script
> if any subtest fails.
>
> Signed-off-by: Sta
On Sun, May 26, 2019 at 3:35 AM Chang-Hsien Tsai wrote:
>
> use fgets() as the while loop condition.
>
> Signed-off-by: Chang-Hsien Tsai
Looks like right now we did not really differentiate error in fgets from EOF,
so the change is in this patch is equivalent to its previous behavior.
Acked-by:
On Fri, Jul 12, 2019 at 11:24 AM Andrii Nakryiko
wrote:
>
> On Fri, Jul 12, 2019 at 10:46 AM Ilya Leoshkevich wrote:
> >
> > Many s390 setups (most notably, KVM guests) do not have access to
> > hardware performance events.
> >
> > Therefore, use the software event instead.
> >
> > Signed-off-by:
On Tue, Jul 16, 2019 at 4:59 AM Ilya Leoshkevich wrote:
>
> test_pkt_md_access is failing on s390, since the associated eBPF prog
> returns TC_ACT_SHOT, which in turn happens because loading a part of a
> struct __sk_buff field produces an incorrect result.
>
> The problem is that when verifier em
[sorry, resend again as previous one has come text messed out due to
networking issues]
On Tue, Jul 16, 2019 at 10:08 PM Y Song wrote:
>
> On Tue, Jul 16, 2019 at 4:59 AM Ilya Leoshkevich wrote:
> >
> > test_pkt_md_access is failing on s390, since the associated eBP
On Wed, Jul 17, 2019 at 3:36 AM Ilya Leoshkevich wrote:
>
> > Am 17.07.2019 um 11:21 schrieb Ilya Leoshkevich :
> >
> >> Am 17.07.2019 um 07:11 schrieb Y Song :
> >>
> >> [sorry, resend again as previous one has come text messed out due to
> >> n
On Wed, Jul 17, 2019 at 1:52 PM Ilya Leoshkevich wrote:
>
> > Am 17.07.2019 um 18:25 schrieb Y Song :
> >
> > On Wed, Jul 17, 2019 at 3:36 AM Ilya Leoshkevich wrote:
> >>
> >>
> >> Here is a better one: len=0x11223344 and we would like to do
>
On Thu, Jul 18, 2019 at 8:01 AM Ilya Leoshkevich wrote:
>
> The very first check in test_pkt_md_access is failing on s390, which
> happens because loading a part of a struct __sk_buff field produces
> an incorrect result.
>
> The preprocessed code of the check is:
>
> {
> __u8 tmp = *((vol
On Fri, Jul 19, 2019 at 7:35 AM Arnaldo Carvalho de Melo
wrote:
>
> From: Arnaldo Carvalho de Melo
>
> Using endian.h and its endianness macros makes this code build in a
> wider range of compilers, as some don't have those macros
> (__BYTE_ORDER__, __ORDER_LITTLE_ENDIAN__, __ORDER_BIG_ENDIAN__),
On Thu, Aug 1, 2019 at 2:04 AM Daniel T. Lee wrote:
>
> By this commit, using `bpftool net attach`, user can attach XDP prog on
> interface. New type of enum 'net_attach_type' has been made, as stated at
> cover-letter, the meaning of 'attach' is, prog will be attached on interface.
>
> BPF prog w
On Thu, Aug 1, 2019 at 2:04 AM Daniel T. Lee wrote:
>
> By this commit, using `bpftool net detach`, the attached XDP prog can
> be detached. Detaching the BPF prog will be done through libbpf
> 'bpf_set_link_xdp_fd' with the progfd set to -1.
>
> Signed-off-by: Daniel T. Lee
> ---
> Changes in v2
On Thu, Aug 1, 2019 at 1:33 AM Daniel T. Lee wrote:
>
> Currently, bpftool net only supports dumping progs attached on the
> interface. To attach XDP prog on interface, user must use other tool
> (eg. iproute2). By this patch, with `bpftool net attach/detach`, user
> can attach/detach XDP prog on
On Sat, Aug 3, 2019 at 8:29 PM Farid Zakaria wrote:
>
> Foo over UDP uses UDP encapsulation to add additional entropy
> into the packets so that they get beter distribution across EMCP
> routes.
>
> Expose udp_flow_src_port as a bpf helper so that tunnel filters
> can benefit from the helper.
>
>
ied for our custom use case.
> >
> > The Linux kernel provides a single abstraction for the src port for UDP
> > tunneling
> > via udp_flow_src_port. If it's improved eBPF filters would benefit if the
> > call is the same.
> >
> > Exposing this fun
On Tue, Aug 6, 2019 at 5:20 PM Jakub Kicinski
wrote:
>
> Hi!
>
> First make sure we don't use "prog" in error messages because
> the pinning operation could be performed on a map. Second add
> back missing error message if pin syscall failed.
>
> Jakub Kicinski (2):
> tools: bpftool: fix error m
On Tue, Aug 6, 2019 at 7:25 PM Daniel T. Lee wrote:
>
> By this commit, using `bpftool net attach`, user can attach XDP prog on
> interface. New type of enum 'net_attach_type' has been made, as stated at
> cover-letter, the meaning of 'attach' is, prog will be attached on interface.
>
> With 'over
On Tue, Aug 6, 2019 at 7:25 PM Daniel T. Lee wrote:
>
> By this commit, using `bpftool net detach`, the attached XDP prog can
> be detached. Detaching the BPF prog will be done through libbpf
> 'bpf_set_link_xdp_fd' with the progfd set to -1.
>
> Signed-off-by: Daniel T. Lee
> ---
> tools/bpf/bp
On Wed, Aug 7, 2019 at 5:37 AM Jesper Dangaard Brouer wrote:
>
> The devmap name 'tx_port' came from a copy-paste from xdp_redirect_map
> which only have a single TX port. Change name to xdp_tx_ports
> to make it more descriptive.
>
> Signed-off-by: Jesper Dangaard Brouer
Acked-by: Yonghong Song
On Wed, Aug 7, 2019 at 5:37 AM Jesper Dangaard Brouer wrote:
>
> This address the TODO in samples/bpf/xdp_fwd_kern.c, which points out
> that the chosen egress index should be checked for existence in the
> devmap. This can now be done via taking advantage of Toke's work in
> commit 0cdbb4b09a06 (
On Wed, Aug 7, 2019 at 5:38 AM Jesper Dangaard Brouer wrote:
>
> Make it clear that this XDP program depend on the network
> stack to do the ARP resolution. This is connected with the
> BPF_FIB_LKUP_RET_NO_NEIGH return code from bpf_fib_lookup().
>
> Another common mistake (seen via XDP-tutorial)
On Wed, Aug 7, 2019 at 11:30 AM Maciej Fijalkowski
wrote:
>
> On Wed, 7 Aug 2019 10:02:04 -0700
> Y Song wrote:
>
> > On Tue, Aug 6, 2019 at 7:25 PM Daniel T. Lee wrote:
> > >
> > > By this commit, using `bpftool net detach`, the attached XDP prog can
>
On Thu, Aug 8, 2019 at 10:52 AM Carlos Antonio Neira Bustos
wrote:
>
> Yonghong,
>
> I have modified the patch following your feedback.
> Let me know if I'm missing something.
Yes, I have some other requests about formating.
https://lore.kernel.org/netdev/20190808174848.poybtaagg5ctle7t@dev00/T/#
On Thu, Aug 8, 2019 at 9:17 AM Jesper Dangaard Brouer wrote:
>
> This address the TODO in samples/bpf/xdp_fwd_kern.c, which points out
> that the chosen egress index should be checked for existence in the
> devmap. This can now be done via taking advantage of Toke's work in
> commit 0cdbb4b09a06 (
On Wed, Aug 7, 2019 at 1:40 PM Maciej Fijalkowski
wrote:
>
> On Wed, 7 Aug 2019 13:12:17 -0700
> Y Song wrote:
>
> > On Wed, Aug 7, 2019 at 11:30 AM Maciej Fijalkowski
> > wrote:
> > >
> > > On Wed, 7 Aug 2019 10:02:04 -0700
> > > Y Song
On Thu, Aug 8, 2019 at 12:43 PM Toke Høiland-Jørgensen wrote:
>
> Alexei Starovoitov writes:
>
> > On Fri, Jul 26, 2019 at 9:06 AM Toke Høiland-Jørgensen
> > wrote:
> >>
> >> This series adds a new map type, devmap_hash, that works like the existing
> >> devmap type, but using a hash-based inde
On Fri, Aug 9, 2019 at 6:35 AM Daniel T. Lee wrote:
>
> By this commit, using `bpftool net attach`, user can attach XDP prog on
> interface. New type of enum 'net_attach_type' has been made, as stated at
> cover-letter, the meaning of 'attach' is, prog will be attached on interface.
>
> With 'over
On Fri, Aug 9, 2019 at 6:35 AM Daniel T. Lee wrote:
>
> By this commit, using `bpftool net detach`, the attached XDP prog can
> be detached. Detaching the BPF prog will be done through libbpf
> 'bpf_set_link_xdp_fd' with the progfd set to -1.
>
> Signed-off-by: Daniel T. Lee
> ---
> tools/bpf/bp
On Sat, Apr 28, 2018 at 9:56 AM, Alexei Starovoitov
wrote:
> On Sat, Apr 28, 2018 at 12:02:04AM -0700, Yonghong Song wrote:
>> The test attached a raw_tracepoint program to sched/sched_switch.
>> It tested to get stack for user space, kernel space and user
>> space with build_id request. It also t
Hi, William,
When compiled the selftests/bpf in my centos 7 based system, I have
the following failures,
clang -I. -I./include/uapi -I../../../include/uapi
-Wno-compare-distinct-pointer-types \
-O2 -target bpf -emit-llvm -c test_tunnel_kern.c -o - | \
llc -march=bpf -mcpu=generic -
On Mon, Apr 30, 2018 at 7:33 AM, Daniel Borkmann wrote:
> On 04/30/2018 04:26 PM, William Tu wrote:
>> Bring the erspan uapi header file so BPF tunnel helpers can use it.
>>
>> Fixes: 933a741e3b82 ("selftests/bpf: bpf tunnel test.")
>> Reported-by: Yonghong Song
>> Signed-off-by: William Tu
>
>
On Sat, Jun 29, 2019 at 11:05 AM Song Liu wrote:
>
> On Sat, Jun 29, 2019 at 11:04 AM Song Liu wrote:
> >
> > On Sat, Jun 29, 2019 at 7:43 AM Jiri Benc wrote:
> > >
> > > Selftests are reporting this failure in test_lwt_seg6local.sh:
> > >
> > > + ip netns exec ns2 ip -6 route add fb00::6 encap
On Mon, Jul 1, 2019 at 1:49 PM Stanislav Fomichev wrote:
>
> Make sure the callback is invoked for syn-ack and data packet.
>
> Cc: Eric Dumazet
> Cc: Priyaranjan Jha
> Cc: Yuchung Cheng
> Cc: Soheil Hassas Yeganeh
> Signed-off-by: Stanislav Fomichev
> ---
> tools/testing/selftests/bpf/Makef
On Mon, Jul 1, 2019 at 1:49 PM Stanislav Fomichev wrote:
>
> Uses new RTT callback to dump stats every second.
>
> $ mkdir -p /tmp/cgroupv2
> $ mount -t cgroup2 none /tmp/cgroupv2
> $ mkdir -p /tmp/cgroupv2/foo
> $ echo $$ >> /tmp/cgroupv2/foo/cgroup.procs
> $ bpftool prog load ./tcp_dumpstats_ker
On Mon, Jul 1, 2019 at 5:07 PM Stanislav Fomichev wrote:
>
> On 07/01, Y Song wrote:
> > On Mon, Jul 1, 2019 at 1:49 PM Stanislav Fomichev wrote:
> > >
> > > Make sure the callback is invoked for syn-ack and data packet.
> > >
> > > Cc: Eric Dumaz
On Mon, Jul 1, 2019 at 5:31 PM Stanislav Fomichev wrote:
>
> On 07/01, Y Song wrote:
> > On Mon, Jul 1, 2019 at 1:49 PM Stanislav Fomichev wrote:
> > >
> > > Uses new RTT callback to dump stats every second.
> > >
> > > $ mkdir -p /tmp/cgro
On Mon, Jul 1, 2019 at 10:47 PM Andrii Nakryiko wrote:
>
> GCC8 started emitting warning about using strncpy with number of bytes
> exactly equal destination size, which is generally unsafe, as can lead
> to non-zero terminated string being copied. Use IFNAMSIZ - 1 as number
> of bytes to ensure n
On Tue, Jul 2, 2019 at 8:17 AM Andrii Nakryiko wrote:
>
> GCC8 started emitting warning about using strncpy with number of bytes
> exactly equal destination size, which is generally unsafe, as can lead
> to non-zero terminated string being copied. Use IFNAMSIZ - 1 as number
> of bytes to ensure na
On Tue, Jul 2, 2019 at 8:40 AM Ilya Leoshkevich wrote:
>
> Use PT_REGS_RC(ctx) instead of ctx->rax, which is not present on s390.
>
> Pass -D__TARGET_ARCH_$(ARCH) to selftests in order to choose a proper
> PT_REGS_RC variant.
>
> Fix s930 -> s390 typo.
>
> On s390, provide the forward declaration
On Tue, Jul 2, 2019 at 9:58 AM Ilya Leoshkevich wrote:
>
> > Am 02.07.2019 um 18:42 schrieb Y Song :
> >
> > On Tue, Jul 2, 2019 at 8:40 AM Ilya Leoshkevich wrote:
> >>
> >> -#elif defined(__s390x__)
> >> - #define bpf_target_s930x
>
On Tue, Jul 2, 2019 at 8:40 AM Ilya Leoshkevich wrote:
>
> Use PT_REGS_RC(ctx) instead of ctx->rax, which is not present on s390.
>
> Pass -D__TARGET_ARCH_$(ARCH) to selftests in order to choose a proper
> PT_REGS_RC variant.
>
> Fix s930 -> s390 typo.
>
> On s390, provide the forward declaration
On Tue, Jul 2, 2019 at 9:14 AM Stanislav Fomichev wrote:
>
> Congestion control team would like to have a periodic callback to
> track some TCP statistics. Let's add a sock_ops callback that can be
> selectively enabled on a socket by socket basis and is executed for
> every RTT. BPF program frequ
On Tue, Jul 2, 2019 at 10:41 AM Jiri Benc wrote:
>
> Selftests are reporting this failure in test_lwt_seg6local.sh:
>
> + ip netns exec ns2 ip -6 route add fb00::6 encap bpf in obj
> test_lwt_seg6local.o sec encap_srh dev veth2
> Error fetching program/map!
> Failed to parse eBPF program: Operati
On Fri, Jun 28, 2019 at 8:26 AM Andrii Nakryiko wrote:
>
> Change BTF-defined map definitions to capture compile-time integer
> values as part of BTF type definition, to avoid split of key/value type
> information and actual type/size/flags initialization for maps.
>
> Signed-off-by: Andrii Nakryi
On Wed, Jul 3, 2019 at 1:10 PM Stanislav Fomichev wrote:
>
> Forgot to add it in the original patch.
>
> Fixes: b55873984dab ("selftests/bpf: test BPF_SOCK_OPS_RTT_CB")
> Reported-by: Andrii Nakryiko
> Signed-off-by: Stanislav Fomichev
Acked-by: Yonghong Song
> ---
> tools/testing/selftests/
On Wed, Jul 3, 2019 at 9:06 AM Ilya Leoshkevich wrote:
>
> BPF_LDX_MEM is used to load the least significant byte of the retrieved
> test_val.index, however, on big-endian machines it ends up retrieving
> the most significant byte.
>
> Use the correct least significant byte offset on big-endian ma
On Wed, Jul 3, 2019 at 2:31 PM Stanislav Fomichev wrote:
>
> Commit 2589726d12a1 ("bpf: introduce bounded loops") caused a change
> in the way some registers liveliness is reported in the test_align.
> Add missing "_w" to a couple of tests. Note, there are no offset
> changes!
>
> Fixes: 2589726d1
On Wed, Jul 3, 2019 at 1:51 PM Stanislav Fomichev wrote:
>
> Take the first x bytes of pt_regs for scalability tests, there is
> no real reason we need x86 specific rax.
>
> Signed-off-by: Stanislav Fomichev
> ---
> tools/testing/selftests/bpf/progs/loop1.c | 3 ++-
> tools/testing/selftests/bpf
On Thu, Jul 4, 2019 at 1:52 AM Ilya Leoshkevich wrote:
>
> BPF_LDX_MEM is used to load the least significant byte of the retrieved
> test_val.index, however, on big-endian machines it ends up retrieving
> the most significant byte.
>
> Use the correct least significant byte offset on big-endian ma
On Thu, Jul 4, 2019 at 1:58 AM Quentin Monnet
wrote:
>
> Add a new "bpftool prog run" subcommand to run a loaded program on input
> data (and possibly with input context) passed by the user.
>
> Print output data (and output context if relevant) into a file or into
> the console. Print return valu
On Fri, Jul 5, 2019 at 1:21 AM Quentin Monnet
wrote:
>
> 2019-07-04 22:49 UTC-0700 ~ Y Song
> > On Thu, Jul 4, 2019 at 1:58 AM Quentin Monnet
> > wrote:
> >>
> >> Add a new "bpftool prog run" subcommand to run a loaded program on input
> >&g
On Fri, Jul 5, 2019 at 9:03 AM Quentin Monnet
wrote:
>
> 2019-07-05 08:42 UTC-0700 ~ Y Song
> > On Fri, Jul 5, 2019 at 1:21 AM Quentin Monnet
> > wrote:
> >>
> >> 2019-07-04 22:49 UTC-0700 ~ Y Song
> >>> On Thu, Jul 4, 2019 at 1:58 AM Quen
On Fri, Jul 5, 2019 at 10:54 AM Quentin Monnet
wrote:
>
> Add a new "bpftool prog run" subcommand to run a loaded program on input
> data (and possibly with input context) passed by the user.
>
> Print output data (and output context if relevant) into a file or into
> the console. Print return val
On Fri, Jul 5, 2019 at 11:14 AM Toke Høiland-Jørgensen wrote:
>
> From: Toke Høiland-Jørgensen
>
> A common pattern when using xdp_redirect_map() is to create a device map
> where the lookup key is simply ifindex. Because device maps are arrays,
> this leaves holes in the map, and the map has to
On Sat, Jul 6, 2019 at 1:47 AM Toke Høiland-Jørgensen wrote:
>
> This series adds a new map type, devmap_hash, that works like the existing
> devmap type, but using a hash-based indexing scheme. This is useful for the
> use
> case where a devmap is indexed by ifindex (for instance for use with th
On Sat, Jul 6, 2019 at 1:47 AM Toke Høiland-Jørgensen wrote:
>
> From: Toke Høiland-Jørgensen
>
> When we changed the device and CPU maps to use linked lists instead of
> bitmaps, we also removed the need for the map_insert_ctx() helpers to keep
> track of the bitmaps inside each map. However, it
On Sat, Jul 6, 2019 at 1:47 AM Toke Høiland-Jørgensen wrote:
>
> From: Toke Høiland-Jørgensen
>
> The subsequent patch to add a new devmap sub-type can re-use much of the
> initialisation and allocation code, so refactor it into separate functions.
>
> Signed-off-by: Toke Høiland-Jørgensen
Acke
On Sat, Jul 6, 2019 at 1:48 AM Toke Høiland-Jørgensen wrote:
>
> From: Toke Høiland-Jørgensen
>
> A common pattern when using xdp_redirect_map() is to create a device map
> where the lookup key is simply ifindex. Because device maps are arrays,
> this leaves holes in the map, and the map has to b
On Mon, Jul 8, 2019 at 2:55 AM Toke Høiland-Jørgensen wrote:
>
> Y Song writes:
>
> > On Sat, Jul 6, 2019 at 1:48 AM Toke Høiland-Jørgensen
> > wrote:
> >>
> >> From: Toke Høiland-Jørgensen
> >>
> >> A common pattern when using xd
FYI.The latest llvm trunk will not emit errors for static variables. The patch
also gives detailed information how to relate a particular static
variable to a particular
relocation.
https://reviews.llvm.org/rL354954
Thanks,
Yonghong
On Fri, Feb 15, 2019 at 12:18 PM Y Song wrote:
>
>
On Wed, Mar 6, 2019 at 3:25 PM Stanislav Fomichev wrote:
>
> CHECK macro implicitly uses duration. We call CHECK() a couple of times
> before duration is initialized from bpf_prog_test_run().
> Explicitly set duration to 0 to avoid compiler warnings.
>
> Fixes: 740f8a657221 ("selftests/bpf: make s
On Wed, Mar 6, 2019 at 1:14 PM Stanislav Fomichev wrote:
>
> A bunch of related changes lumped together:
> * Create prog_tests and verifier output directories; these don't exist with
> out-of-tree $(OUTPUT)
> * Add missing -I (via separate TEST_{PROGS,VERIFIER}_CFLAGS) for the main tree
> ($(P
On Wed, Mar 6, 2019 at 1:14 PM Stanislav Fomichev wrote:
>
> libbpf targets don't explicitly depend on fixdep target, so when
> we do 'make -j$(nproc)', there is a high probability, that some
> objects will be built before fixdep binary is available.
>
> Fix this by running sub-make; this makes su
On Wed, Mar 6, 2019 at 1:15 PM Willem de Bruijn
wrote:
>
> From: Willem de Bruijn
>
> BPF can adjust gso only for tcp bytestreams. Fail on other gso types.
>
> But only on gso packets. It does not touch this field if !gso_size.
Could you specify which field you are referring here?
gso_type, gso_s
On Thu, Mar 7, 2019 at 10:12 PM Bo YU wrote:
>
> Sparse warning below:
>
> sudo make C=2 CF=-D__CHECK_ENDIAN__ M=net/bpf/
> CHECK net/bpf//test_run.c
> net/bpf//test_run.c:19:77: warning: Using plain integer as NULL pointer
> ./include/linux/bpf-cgroup.h:295:77: warning: Using plain integer as N
On Mon, Mar 11, 2019 at 12:32 PM Martynas Pumputis wrote:
>
> It has been observed that sometimes a higher order memory allocation
> for BPF maps fails when there is no obvious memory pressure in a system.
>
> E.g. the map (BPF_MAP_TYPE_LRU_HASH, key=38, value=56, max_elems=524288)
> could not be
On Mon, Mar 18, 2019 at 6:03 AM Naresh Kamboju
wrote:
>
> selftests: bpf: test_align failed on all devices ( arm64, armv7,
> x86_64 and i386) running Linux -next kernel 5.1.0-rc1 tag:
> next-20190318.
>
> Here is the log from arm64,
>
> selftests: bpf: test_align
> Test 0: mov ... Failed to find
On Tue, Apr 23, 2019 at 6:02 PM Daniel T. Lee wrote:
>
> Oh, I've found what's the problem.
> About the files you've mentioned, nothing seems to matter on my system.
> But the problem is the order of the '-I' option matters.
>
> user@host:~/linux/samples/bpf $ make -n
>
> gcc -Wp,-MD,./sam
On Mon, Apr 29, 2019 at 2:53 AM Quentin Monnet
wrote:
>
> libbpf has three levels of priority for output: warn, info, debug. By
> default, debug output is not printed to stderr.
>
> Add a new "--log-libbpf LOG_LEVEL" option to bpftool to provide more
> flexibility on the log level for libbpf. LOG_
On Tue, Apr 30, 2019 at 2:34 AM Quentin Monnet
wrote:
>
> Hi Yonghong,
>
> 2019-04-29 16:32 UTC-0700 ~ Y Song
> > On Mon, Apr 29, 2019 at 2:53 AM Quentin Monnet
> > wrote:
> >>
> >> libbpf has three levels of priority for output: warn, info, debug. By
On Thu, May 2, 2019 at 11:34 AM William Tu wrote:
>
> The libbpf_util.h is used by xsk.h, so add it to
> the install headers.
Can we try to change code a little bit to avoid exposing libbpf_util.h?
Originally libbpf_util.h is considered as libbpf internal.
I am not strongly against this patch. Bu
On Fri, May 3, 2019 at 12:54 PM William Tu wrote:
>
> On Thu, May 2, 2019 at 1:18 PM Y Song wrote:
> >
> > On Thu, May 2, 2019 at 11:34 AM William Tu wrote:
> > >
> > > The libbpf_util.h is used by xsk.h, so add it to
> > > the install headers.
>
On Thu, Mar 29, 2018 at 2:18 PM, Daniel Borkmann wrote:
> On 03/29/2018 11:04 PM, syzbot wrote:
>> Hello,
>>
>> syzbot hit the following crash on upstream commit
>> 3eb2ce825ea1ad89d20f7a3b5780df850e4be274 (Sun Mar 25 22:44:30 2018 +)
>> Linux 4.16-rc7
>> syzbot dashboard link:
>> https://syz
On Thu, Sep 21, 2017 at 8:52 AM, Alexei Starovoitov
wrote:
> On Thu, Sep 21, 2017 at 04:09:34PM +0100, Edward Cree wrote:
>> print_bpf_insn() was treating all BPF_ALU[64] the same, but BPF_END has a
>> different structure: it has a size in insn->imm (even if it's BPF_X) and
>> uses the BPF_SRC (
On Thu, Sep 21, 2017 at 9:24 AM, Edward Cree wrote:
> On 21/09/17 16:52, Alexei Starovoitov wrote:
>> On Thu, Sep 21, 2017 at 04:09:34PM +0100, Edward Cree wrote:
>>> print_bpf_insn() was treating all BPF_ALU[64] the same, but BPF_END has a
>>> different structure: it has a size in insn->imm (eve
On Thu, Sep 21, 2017 at 12:58 PM, Edward Cree wrote:
> On 21/09/17 20:44, Alexei Starovoitov wrote:
>> On Thu, Sep 21, 2017 at 09:29:33PM +0200, Daniel Borkmann wrote:
>>> More intuitive, but agree on the from_be/le. Maybe we should
>>> just drop the "to_" prefix altogether, and leave the rest as
On Fri, Sep 22, 2017 at 6:46 AM, Edward Cree wrote:
> On 22/09/17 00:11, Y Song wrote:
>> On Thu, Sep 21, 2017 at 12:58 PM, Edward Cree wrote:
>>> On 21/09/17 20:44, Alexei Starovoitov wrote:
>>>> On Thu, Sep 21, 2017 at 09:29:33PM +0200, Daniel Borkmann wrote:
>
On Fri, Sep 22, 2017 at 7:11 AM, Y Song wrote:
> On Fri, Sep 22, 2017 at 6:46 AM, Edward Cree wrote:
>> On 22/09/17 00:11, Y Song wrote:
>>> On Thu, Sep 21, 2017 at 12:58 PM, Edward Cree wrote:
>>>> On 21/09/17 20:44, Alexei Starovoitov wrote:
>>>>
On Fri, Sep 22, 2017 at 9:23 AM, Edward Cree wrote:
> On 22/09/17 16:16, Alexei Starovoitov wrote:
>> looks like we're converging on
>> "be16/be32/be64/le16/le32/le64 #register" for BPF_END.
>> I guess it can live with that. I would prefer more C like syntax
>> to match the rest, but llvm parsing
On Fri, Sep 14, 2018 at 12:24 PM Alexei Starovoitov
wrote:
>
> On Fri, Sep 14, 2018 at 07:46:17AM -0700, Petar Penkov wrote:
> > From: Petar Penkov
> >
> > This patch series hardens the RX stack by allowing flow dissection in BPF,
> > as previously discussed [1]. Because of the rigorous checks of
On Mon, Sep 17, 2018 at 10:32 AM John Fastabend
wrote:
>
> After this patch we only allow socks that are in ESTABLISHED state or
> are being added via a sock_ops event that is transitioning into an
> ESTABLISHED state. By allowing sock_ops events we allow users to
> manage sockmaps directly from s
On Mon, Sep 17, 2018 at 10:32 AM John Fastabend
wrote:
>
> It is possible (via shutdown()) for TCP socks to go trough TCP_CLOSE
> state via tcp_disconnect() without actually calling tcp_close which
> would then call our bpf_tcp_close() callback. Because of this a user
> could disconnect a socket t
On Mon, Sep 17, 2018 at 10:33 AM John Fastabend
wrote:
>
> Ensure that sockets added to a sock{map|hash} that is not in the
> ESTABLISHED state is rejected.
>
> Fixes: 1aa12bdf1bfb ("bpf: sockmap, add sock close() hook to remove socks")
> Signed-off-by: John Fastabend
> ---
> tools/testing/selft
On Mon, Sep 17, 2018 at 9:39 PM John Fastabend wrote:
>
> It is possible (via shutdown()) for TCP socks to go trough TCP_CLOSE
> state via tcp_disconnect() without actually calling tcp_close which
> would then call our bpf_tcp_close() callback. Because of this a user
> could disconnect a socket th
On Mon, Sep 17, 2018 at 9:38 PM John Fastabend wrote:
>
> Ensure that sockets added to a sock{map|hash} that is not in the
> ESTABLISHED state is rejected.
>
> Fixes: 1aa12bdf1bfb ("bpf: sockmap, add sock close() hook to remove socks")
> Signed-off-by: John Fastabend
Acked-by: Yonghong Song
On Tue, Sep 18, 2018 at 3:13 AM Magnus Karlsson
wrote:
>
> Previously, the xsk code did not record which umem was bound to a
> specific queue id. This was not required if all drivers were zero-copy
> enabled as this had to be recorded in the driver anyway. So if a user
> tried to bind two umems to
On Tue, Sep 18, 2018 at 10:15 AM Jakub Kicinski
wrote:
>
> libc_compat.h is used by libbpf so make sure it's licensed under
> LGPL or BSD license. The license change should be OK, I'm the only
> author of the file.
>
> Signed-off-by: Jakub Kicinski
> Reviewed-by: Quentin Monnet
Acked-by: Yongh
On Tue, Sep 18, 2018 at 1:20 PM Willem de Bruijn
wrote:
>
> From: Willem de Bruijn
>
> If boolean CONFIG_BPF_SYSCALL is enabled, kernel/bpf/syscall.c will
> call flow_dissector functions from net/core/flow_dissector.c.
>
> This causes this build failure if CONFIG_NET is disabled:
>
> kernel/b
On Wed, Sep 19, 2018 at 12:15 AM Magnus Karlsson
wrote:
>
> On Tue, Sep 18, 2018 at 7:23 PM Y Song wrote:
> >
> > On Tue, Sep 18, 2018 at 3:13 AM Magnus Karlsson
> > wrote:
> > >
> > > Previously, the xsk code did not record which umem was bound
On Fri, Jan 12, 2018 at 11:23 AM, Daniel Borkmann wrote:
> syzkaller generated a BPF proglet and triggered a warning with
> the following:
>
> 0: (b7) r0 = 0
> 1: (d5) if r0 s<= 0x0 goto pc+0
>R0=inv0 R1=ctx(id=0,off=0,imm=0) R10=fp0
> 2: (1f) r0 -= r1
>R0=inv0 R1=ctx(id=0,off=0,imm=
On Mon, Jan 15, 2018 at 2:40 AM, Daniel Borkmann wrote:
> On 01/15/2018 07:38 AM, Y Song wrote:
>> On Fri, Jan 12, 2018 at 11:23 AM, Daniel Borkmann
>> wrote:
> [...]
>>>
>>> I've been thinking to additionally reject arithmetic on ctx
>>> poi
When compiling latest bpf-next, I hit the following compilation error:
clang -I. -I./include/uapi -I../../../include/uapi -idirafter
/usr/local/include -idirafter
/data/users/yhs/work/llvm/build/install/lib/clang/7.0.0/include
-idirafter /usr/include -Wno-compare-distinct-pointer-types \
sting/selftests/bpf/test_lwt_seg6local.o
> test_lwt_seg6local.c:4:10: fatal error: 'linux/seg6_local.h' file not found
> ^~~~
> 1 error generated.
> make: Leaving directory
> `/data/users/yhs/work/net-next/tools/testing/selftests/bpf'
>
> Reported-by: Y
On Fri, May 25, 2018 at 9:16 AM, Y Song wrote:
> On Fri, May 25, 2018 at 4:20 AM, Mathieu Xhonneux
> wrote:
>> Previous patch "selftests/bpf: test for seg6local End.BPF action" lacks
>> some UAPI headers in tools/.
>>
>> clang -I. -I./include/uapi -I
On Fri, May 25, 2018 at 8:21 AM, Alban Crequy wrote:
> On Wed, May 23, 2018 at 4:34 AM Y Song wrote:
>
>> I did a quick prototyping and the above interface seems working fine.
>
> Thanks! I gave your kernel patch & userspace program a try and it works for
> me on cgroup-
On Thu, Jun 7, 2018 at 8:40 AM, Daniel Borkmann wrote:
> As commit 28e33f9d78ee ("bpf: disallow arithmetic operations on
> context pointer") already describes, f1174f77b50c ("bpf/verifier:
> rework value tracking") removed the specific white-listed cases
> we had previously where we would allow fo
On Mon, Jun 11, 2018 at 4:57 AM, Björn Töpel wrote:
> From: Björn Töpel
>
> syzkaller reported a warning from xdp_umem_pin_pages():
>
> WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70
> mm/slab_common.c:996
> ...
> __do_kmalloc mm/slab.c:3713 [inline]
> __kmalloc
On Mon, Jun 11, 2018 at 11:47 AM, John Fastabend
wrote:
> In selftest test_maps the sockmap test case attempts to add a socket
> in listening state to the sockmap. This is no longer a valid operation
> so it fails as expected. However, the test wrongly reports this as an
> error now. Fix the test
1 - 100 of 186 matches
Mail list logo
