bpf.2: Improvements after comments by Alexei Starovoitov

Reported-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2015-07-22 22:02:27 +02:00
parent dc079fa280
commit 46a4949bd7
1 changed files with 11 additions and 28 deletions

View File

@ -66,18 +66,7 @@ and access shared data structures such as eBPF maps.
BPF maps are a generic data structure for storage of different data types.
A user process can create multiple maps (with key/value-pairs being
opaque bytes of data) and access them via file descriptors.
eBPF programs can access maps from inside the kernel in parallel.
.\"
.\" FIXME!! What does the previous sentence mean?
.\"
.\" Isn't "from inside the kernel" redundant? (I mean: all eBPF programs
.\" are running inside the kernel, right?)
.\" And what does "in parallel" mean?
.\" Would a simpler version of this sentence be correct? As in:
.\" "Different eBPF programs can access the same maps in parallel."
.\" ?
.\" (Actually, the page already says something like that lower down.)
.\"
Differnt eBPF programs can access the same maps in parallel.
It's up to the user process and eBPF program to decide what they store
inside maps.
.P
@ -273,8 +262,7 @@ and attributes as specified in
.IR value_size ,
and
.IR max_entries .
.\" FIXME!! In the next sentence, what does "process-local" mean?
On success, this operation returns a process-local file descriptor.
On success, this operation returns a file descriptor.
On error, \-1 is returned and
.I errno
is set to
@ -311,11 +299,13 @@ since the in-kernel helper function
bpf_map_lookup_elem(map_fd, void *key)
expects to read 8 bytes from
.I key
pointer, but
expects to read 8 bytes from the location pointed to by
.IR key ,
but the
.IR "fp\ -\ 4"
.\" FIXME!! I'm lost! What is 'fp' in this context?
(where
.I fp
is the top of the stack)
starting address will cause out-of-bounds stack access.
Similarly, when a map is created with a
@ -562,15 +552,12 @@ The following map types are supported:
.TP
.B BPF_MAP_TYPE_HASH
.\" commit 0f8e4bd8a1fc8c4185f1630061d0a1f2d197a475
.\" FIXME!! Please review the following list of points, which draws
.\" heavily from the commit message, but reworks the text significantly
.\" and so may have introduced errors.
Hash-table maps have the following characteristics:
.RS
.IP * 3
Maps are created and destroyed by user-space programs.
Both user-space and eBPF programs
can perform lookuo, update, and delete operations.
can perform lookup, update, and delete operations.
.IP *
The kernel takes care of allocating and freeing key/value pairs.
.IP *
@ -590,14 +577,11 @@ optimized for speed of lookup.
.TP
.B BPF_MAP_TYPE_ARRAY
.\" commit 28fbcfa08d8ed7c5a50d41a0433aad222835e8e3
.\" FIXME!! Please review the following list of points, which draws
.\" heavily from the commit message, but reworks the text significantly
.\" and so may have introduced errors.
Array maps have the following characteristics:
.RS
.IP * 3
Optimized for fastest possible lookup.
In the future ithe verifier/JIT compiler
In the future the verifier/JIT compiler
may recognize lookup() operations that employ a constant key
and optimize it into constant pointer.
It is possible to optimize a non-constant
@ -634,7 +618,7 @@ Aggregation of tracing events into a fixed set of buckets.
.RE
.TP
.BR BPF_MAP_TYPE_PROG_ARRAY " (since Linux 4.2)"
.\" FIXME: we need documentation of BPF_MAP_TYPE_PROG_ARRAY
.\" FIXME we need documentation of BPF_MAP_TYPE_PROG_ARRAY
[To be completed]
.\"
.SS eBPF programs
@ -1037,7 +1021,6 @@ commands require the caller to have the
.B CAP_SYS_ADMIN
capability.
.\" FIXME!! Alexei, is the following correct?
eBPF objects (maps and programs) can be shared between processes.
For example, after
.BR fork (2),