linux.git/tools/bpf/bpftool/map.c, branch v4.18

tools/bpftool: fix a percpu_array map dump problem

2018-07-30T22:37:09+00:00

I hit the following problem when I tried to use bpftool
to dump a percpu array.

  $ sudo ./bpftool map show
  61: percpu_array  name stub  flags 0x0
          key 4B  value 4B  max_entries 1  memlock 4096B
  ...
  $ sudo ./bpftool map dump id 61
  bpftool: malloc.c:2406: sysmalloc: Assertion
  `(old_top == initial_top (av) && old_size == 0) || \
   ((unsigned long) (old_size) >= MINSIZE && \
   prev_inuse (old_top) && \
   ((unsigned long) old_end & (pagesize - 1)) == 0)'
  failed.
  Aborted

Further debugging revealed that this is due to
miscommunication between bpftool and kernel.
For example, for the above percpu_array with value size of 4B.
The map info returned to user space has value size of 4B.

In bpftool, the values array for lookup is allocated like:
   info->value_size * get_possible_cpus() = 4 * get_possible_cpus()
In kernel (kernel/bpf/syscall.c), the values array size is
rounded up to multiple of 8.
   round_up(map->value_size, 8) * num_possible_cpus()
   = 8 * num_possible_cpus()
So when kernel copies the values to user buffer, the kernel will
overwrite beyond user buffer boundary.

This patch fixed the issue by allocating and stepping through
percpu map value array properly in bpftool.

Fixes: 71bb428fe2c19 ("tools: bpf: add bpftool")
Signed-off-by: Yonghong Song 
Signed-off-by: Daniel Borkmann

bpf: bpftool, support for sockhash

2018-05-16T20:00:21+00:00

This adds the SOCKHASH map type to bpftools so that we get correct
pretty printing.

Signed-off-by: John Fastabend 
Acked-by: David S. Miller 
Signed-off-by: Daniel Borkmann

tools: bpftool: add simple perf event output reader

2018-05-04T21:41:04+00:00

Users of BPF sooner or later discover perf_event_output() helpers
and BPF_MAP_TYPE_PERF_EVENT_ARRAY.  Dumping this array type is
not possible, however, we can add simple reading of perf events.
Create a new event_pipe subcommand for maps, this sub command
will only work with BPF_MAP_TYPE_PERF_EVENT_ARRAY maps.

Parts of the code from samples/bpf/trace_output_user.c.

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

tools: bpftool: move get_possible_cpus() to common code

2018-05-04T21:41:04+00:00

Move the get_possible_cpus() function to shared code.  No functional
changes.

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

tools: bpftool: fold hex keyword in command help

2018-05-04T21:41:04+00:00

Instead of spelling [hex] BYTES everywhere use DATA as keyword
for generalized value.  This will help us keep the messages
concise when longer command are added in the future.  It will
also be useful once BTF support comes.  We will only have to
change the definition of DATA.

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

tools: bpftool: make it easier to feed hex bytes to bpftool

2018-04-18T12:49:27+00:00

bpftool uses hexadecimal values when it dumps map contents:

    # bpftool map dump id 1337
    key: ff 13 37 ff  value: a1 b2 c3 d4 ff ff ff ff
    Found 1 element

In order to lookup or update values with bpftool, the natural reflex is
then to copy and paste the values to the command line, and to try to run
something like:

    # bpftool map update id 1337 key ff 13 37 ff \
            value 00 00 00 00 00 00 1a 2b
    Error: error parsing byte: ff

bpftool complains, because it uses strtoul() with a 0 base to parse the
bytes, and that without a "0x" prefix, the bytes are considered as
decimal values (or even octal if they start with "0").

To feed hexadecimal values instead, one needs to add "0x" prefixes
everywhere necessary:

    # bpftool map update id 1337 key 0xff 0x13 0x37 0xff \
            value 0 0 0 0 0 0 0x1a 0x2b

To make it easier to use hexadecimal values, add an optional "hex"
keyword to put after "key" or "value" to tell bpftool to consider the
digits as hexadecimal. We can now do:

    # bpftool map update id 1337 key hex ff 13 37 ff \
            value hex 0 0 0 0 0 0 1a 2b

Without the "hex" keyword, the bytes are still parsed according to
normal integer notation (decimal if no prefix, or hexadecimal or octal
if "0x" or "0" prefix is used, respectively).

The patch also add related documentation and bash completion for the
"hex" keyword.

Suggested-by: Daniel Borkmann 
Suggested-by: David Beckett 
Signed-off-by: Quentin Monnet 
Acked-by: Jakub Kicinski 
Signed-off-by: Daniel Borkmann

tools: bpftool: don't use hex numbers in JSON output

2018-03-24T17:38:59+00:00

JSON does not accept hex numbers with 0x prefix.  Simply print
as decimal numbers, JSON should be primarily machine-readable.

Signed-off-by: Jakub Kicinski 
Reviewed-by: Quentin Monnet 
Fixes: 831a0aafe5c3 ("tools: bpftool: add JSON output for `bpftool map *` commands")
Signed-off-by: Alexei Starovoitov

bpftool: recognize BPF_MAP_TYPE_CPUMAP maps

2018-01-19T22:16:52+00:00

Add BPF_MAP_TYPE_CPUMAP map type to the list
of map type recognized by bpftool and define
corresponding text representation.

Signed-off-by: Roman Gushchin 
Cc: Quentin Monnet 
Cc: Jakub Kicinski 
Cc: Daniel Borkmann 
Cc: Alexei Starovoitov 
Acked-by: Quentin Monnet 
Signed-off-by: Daniel Borkmann

tools: bpftool: report device information for offloaded maps

2018-01-18T21:54:25+00:00

Print the information about device on which map is created.

Signed-off-by: Jakub Kicinski 
Signed-off-by: Daniel Borkmann

tools: bpftool: alias show and list commands

2018-01-04T11:28:46+00:00

iproute2 seems to accept show and list as aliases.
Let's do the same thing, and by allowing both bring
cgroup syntax back in line with maps and progs.

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