linux-stable.git/tools/bpf, branch linux-5.0.y

bpftool: exclude bash-completion/bpftool from .gitignore pattern

2019-05-31T13:44:52+00:00

[ Upstream commit a7d006714724de4334c5e3548701b33f7b12ca96 ]

tools/bpf/bpftool/.gitignore has the "bpftool" pattern, which is
intended to ignore the following build artifact:

  tools/bpf/bpftool/bpftool

However, the .gitignore entry is effective not only for the current
directory, but also for any sub-directories.

So, from the point of .gitignore grammar, the following check-in file
is also considered to be ignored:

  tools/bpf/bpftool/bash-completion/bpftool

As the manual gitignore(5) says "Files already tracked by Git are not
affected", this is not a problem as far as Git is concerned.

However, Git is not the only program that parses .gitignore because
.gitignore is useful to distinguish build artifacts from source files.

For example, tar(1) supports the --exclude-vcs-ignore option. As of
writing, this option does not work perfectly, but it intends to create
a tarball excluding files specified by .gitignore.

So, I believe it is better to fix this issue.

You can fix it by prefixing the pattern with a slash; the leading slash
means the specified pattern is relative to the current directory.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Quentin Monnet 
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Sasha Levin

tools: bpftool: fix infinite loop in map create

2019-05-25T16:22:27+00:00

[ Upstream commit 8694d8c1f82cccec9380e0d3720b84eee315dfb7 ]

"bpftool map create" has an infinite loop on "while (argc)". The error
case is missing.

Symptoms: when forgetting to type the keyword 'type' in front of 'hash':
$ sudo bpftool map create /sys/fs/bpf/dir/foobar hash key 8 value 8 entries 128
(infinite loop, taking all the CPU)
^C

After the patch:
$ sudo bpftool map create /sys/fs/bpf/dir/foobar hash key 8 value 8 entries 128
Error: unknown arg hash

Fixes: 0b592b5a01be ("tools: bpftool: add map create command")
Signed-off-by: Alban Crequy 
Reviewed-by: Quentin Monnet 
Acked-by: Song Liu 
Reviewed-by: Jakub Kicinski 
Signed-off-by: Daniel Borkmann 
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Sasha Levin

tools: bpftool: fix crash with un-owned prog arrays

2019-01-28T22:59:46+00:00

Prog arrays don't have 'owner_prog_type' and 'owner_jited'
fields in their fdinfo when they are created.  Those fields
are set and reported when first program is checked for
compatibility by bpf_prog_array_compatible().

This means that bpftool cannot expect the fields to always
be there.  Currently trying to show maps on a system with
an un-owned prog array leads to a crash:

$ bpftool map show
389: prog_array  name tail_call_map  flags 0x0
Error: key 'owner_prog_type' not found in fdinfo
Error: key 'owner_jited' not found in fdinfo
       key 4B  value 4B  max_entries 4  memlock 4096B
       Segmentation fault (core dumped)

We pass a NULL pointer to atoi().

Remove the assumption that fdinfo keys are always present.
Add missing validations and remove the p_err() calls which
may lead to broken JSON output as caller will not propagate
the failure.

Fixes: 99a44bef5870 ("tools: bpftool: add owner_prog_type and owner_jited to bpftool output")
Signed-off-by: Jakub Kicinski 
Reviewed-by: Quentin Monnet 
Acked-by: Song Liu 
Signed-off-by: Daniel Borkmann

bpftool: fix percpu maps updating

2019-01-23T08:56:20+00:00

When updating a percpu map, bpftool currently copies the provided
value only into the first per CPU copy of the specified value,
all others instances are left zeroed.

This change explicitly copies the user-provided bytes to all the
per CPU instances, keeping the sub-command syntax unchanged.

v2 -> v3:
 - drop unused argument, as per Quentin's suggestion
v1 -> v2:
 - rename the helper as per Quentin's suggestion

Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool")
Signed-off-by: Paolo Abeni 
Reviewed-by: Quentin Monnet 
Signed-off-by: Daniel Borkmann

bpftool: Fix prog dump by tag

2019-01-23T08:52:12+00:00

Lance reported an issue with bpftool not being able to
dump program if there are more programs loaded and you
want to dump any but the first program, like:

  # bpftool prog
  28: kprobe  name trace_req_start  tag 1dfc28ba8b3dd597  gpl
  	loaded_at 2019-01-18T17:02:40+1100  uid 0
  	xlated 112B  jited 109B  memlock 4096B  map_ids 13
  29: kprobe  name trace_req_compl  tag 5b6a5ecc6030a683  gpl
  	loaded_at 2019-01-18T17:02:40+1100  uid 0
  	xlated 928B  jited 575B  memlock 4096B  map_ids 13,14
  #  bpftool prog dum jited tag 1dfc28ba8b3dd597
   0:	push   %rbp
   1:	mov    %rsp,%rbp
  ...

  #  bpftool prog dum jited tag 5b6a5ecc6030a683
  Error: can't get prog info (29): Bad address

The problem is in the prog_fd_by_tag function not cleaning
the struct bpf_prog_info before another request, so the
previous program length is still in there and kernel assumes
it needs to dump the program, which fails because there's no
user pointer set.

Moving the struct bpf_prog_info declaration into the loop,
so it gets cleaned before each query.

Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool")
Reported-by: Lance Digby 
Signed-off-by: Jiri Olsa 
Reviewed-by: Quentin Monnet 
Acked-by: Jakub Kicinski 
Signed-off-by: Daniel Borkmann

tools: bpftool: Cleanup license mess

2019-01-18T23:26:54+00:00

Precise and non-ambiguous license information is important. The recent
relicensing of the bpftools introduced a license conflict.

The files have now:

     SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause

and

     * This program is free software; you can redistribute it and/or
     * modify it under the terms of the GNU General Public License
     * as published by the Free Software Foundation; either version
     * 2 of the License, or (at your option) any later version

Amazingly about 20 people acked that change and neither they nor the
committer noticed. Oh well.

Digging deeper: The files were imported from the iproute2 repository with
the GPL V2 or later boiler plate text in commit b66e907cfee2 ("tools:
bpftool: copy JSON writer from iproute2 repository")

Looking at the iproute2 repository at

  git://git.kernel.org/pub/scm/network/iproute2/iproute2.git

the following commit is the equivivalent:

  commit d9d8c839 ("json_writer: add SPDX Identifier (GPL-2/BSD-2)")

That commit explicitly removes the boiler plate and relicenses the code
uner GPL-2.0-only and BSD-2-Clause. As Steven wrote the original code and
also the relicensing commit, it's assumed that the relicensing was intended
to do exaclty that. Just the kernel side update failed to remove the boiler
plate. Do so now.

Fixes: 907b22365115 ("tools: bpftool: dual license all files")
Signed-off-by: Thomas Gleixner 
Cc: Jakub Kicinski 
Cc: Roman Gushchin 
Cc: YueHaibing 
Cc: Yonghong Song 
Cc: Stanislav Fomichev 
Cc: Sean Young 
Cc: Jiri Benc 
Cc: David Calavera 
Cc: Andrey Ignatov 
Cc: Joe Stringer 
Cc: David Ahern 
Cc: Alexei Starovoitov 
Cc: Petar Penkov 
Cc: Sandipan Das 
Cc: Prashant Bhole 
Cc: Stephen Hemminger 
Cc: John Fastabend 
Cc: Taeung Song 
Cc: Jiri Olsa 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Quentin Monnet 
CC: okash.khawaja@gmail.com
Cc: netdev@vger.kernel.org
Acked-by: Jakub Kicinski 
Signed-off-by: Alexei Starovoitov

tools/bpf: properly account for libbfd variations

2019-01-15T23:53:48+00:00

On some platforms, in order to link against libbfd, we need to
link against liberty and even possibly libz. Account for that
in the bpftool Makefile. We now have proper feature detection
for each case, so handle each one separately.

See recent commit 14541b1e7e72 ("perf build: Don't unconditionally link the
libbfd feature test to -liberty and -lz") where I fixed feature
detection.

v2 (addressed Jakub's nits):
  * better syntax for 'else ifeq'
  * no space between ifeq args
v3:
  * use LIBS, not EXTLIBS for -DHAVE_LIBBFD_SUPPORT

Fixes: 29a9c10e4110 ("bpftool: make libbfd optional")
Signed-off-by: Stanislav Fomichev 
Acked-by: Jakub Kicinski 
Signed-off-by: Daniel Borkmann

tools/bpf: fix bpftool map dump with bitfields

2019-01-11T09:40:54+00:00

Commit 8772c8bc093b ("tools: bpftool: support pretty print
with kind_flag set") added bpftool map dump with kind_flag
support. When bitfield_size can be retrieved directly from
btf_member, function btf_dumper_bitfield() is called to
dump the bitfield. The implementation passed the
wrong parameter "bit_offset" to the function. The excepted
value is the bit_offset within a byte while the passed-in
value is the struct member offset.

This commit fixed the bug with passing correct "bit_offset"
with adjusted data pointer.

Fixes: 8772c8bc093b ("tools: bpftool: support pretty print with kind_flag set")
Acked-by: Martin KaFai Lau 
Signed-off-by: Yonghong Song 
Signed-off-by: Daniel Borkmann

tools: bpftool: do not force gcc as CC

2018-12-19T20:57:25+00:00

This allows transparent cross-compilation with CROSS_COMPILE by
relying on 7ed1c1901fe5 ("tools: fix cross-compile var clobbering").

Signed-off-by: Ivan Babrou 
Signed-off-by: Daniel Borkmann

tools: bpftool: add an option to prevent auto-mount of bpffs, tracefs

2018-12-18T13:47:17+00:00

In order to make life easier for users, bpftool automatically attempts
to mount the BPF virtual file system, if it is not mounted already,
before trying to pin objects in it. Similarly, it attempts to mount
tracefs if necessary before trying to dump the trace pipe to the
console.

While mounting file systems on-the-fly can improve user experience, some
administrators might prefer to avoid that. Let's add an option to block
these mount attempts. Note that it does not prevent automatic mounting
of tracefs by debugfs for the "bpftool prog tracelog" command.

Signed-off-by: Quentin Monnet 
Reviewed-by: Jakub Kicinski 
Signed-off-by: Daniel Borkmann