Commit e1289cfb authored by David S. Miller's avatar David S. Miller
Browse files

Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next 



Daniel Borkmann says:

====================
pull-request: bpf-next 2021-06-28

The following pull-request contains BPF updates for your *net-next* tree.

We've added 37 non-merge commits during the last 12 day(s) which contain
a total of 56 files changed, 394 insertions(+), 380 deletions(-).

The main changes are:

1) XDP driver RCU cleanups, from Toke Høiland-Jørgensen and Paul E. McKenney.

2) Fix bpf_skb_change_proto() IPv4/v6 GSO handling, from Maciej Żenczykowski.

3) Fix false positive kmemleak report for BPF ringbuf alloc, from Rustam Kovhaev.

4) Fix x86 JIT's extable offset calculation for PROBE_LDX NULL, from Ravi Bangoria.

5) Enable libbpf fallback probing with tracing under RHEL7, from Jonathan Edwards.

6) Clean up x86 JIT to remove unused cnt tracking from EMIT macro, from Jiri Olsa.

7) Netlink cleanups for libbpf to please Coverity, from Kumar Kartikeya Dwivedi.

8) Allow to retrieve ancestor cgroup id in tracing programs, from Namhyung Kim.

9) Fix lirc BPF program query to use user-provided prog_cnt, from Sean Young.

10) Add initial libbpf doc including generated kdoc for its API, from Grant Seltzer.

11) Make xdp_rxq_info_unreg_mem_model() more robust, from Jakub Kicinski.

12) Fix up bpfilter startup log-level to info level, from Gary Lin.
====================

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parents 1fd07f33 a78cae24

Documentation/RCU/checklist.rst

+34 −21
Original line number Diff line number Diff line
@@ -211,27 +211,40 @@ over a rather long period of time, but improvements are always welcome! 
	of the system, especially to real-time workloads running on

	the rest of the system.



7.	As of v4.20, a given kernel implements only one RCU flavor,

	which is RCU-sched for PREEMPTION=n and RCU-preempt for PREEMPTION=y.

	If the updater uses call_rcu() or synchronize_rcu(),

	then the corresponding readers may use rcu_read_lock() and

	rcu_read_unlock(), rcu_read_lock_bh() and rcu_read_unlock_bh(),

	or any pair of primitives that disables and re-enables preemption,

	for example, rcu_read_lock_sched() and rcu_read_unlock_sched().

	If the updater uses synchronize_srcu() or call_srcu(),

	then the corresponding readers must use srcu_read_lock() and

	srcu_read_unlock(), and with the same srcu_struct.  The rules for

	the expedited primitives are the same as for their non-expedited

	counterparts.  Mixing things up will result in confusion and

	broken kernels, and has even resulted in an exploitable security

	issue.



	One exception to this rule: rcu_read_lock() and rcu_read_unlock()

	may be substituted for rcu_read_lock_bh() and rcu_read_unlock_bh()

	in cases where local bottom halves are already known to be

	disabled, for example, in irq or softirq context.  Commenting

	such cases is a must, of course!  And the jury is still out on

	whether the increased speed is worth it.

7.	As of v4.20, a given kernel implements only one RCU flavor, which

	is RCU-sched for PREEMPTION=n and RCU-preempt for PREEMPTION=y.

	If the updater uses call_rcu() or synchronize_rcu(), then

	the corresponding readers may use:  (1) rcu_read_lock() and

	rcu_read_unlock(), (2) any pair of primitives that disables

	and re-enables softirq, for example, rcu_read_lock_bh() and

	rcu_read_unlock_bh(), or (3) any pair of primitives that disables

	and re-enables preemption, for example, rcu_read_lock_sched() and

	rcu_read_unlock_sched().  If the updater uses synchronize_srcu()

	or call_srcu(), then the corresponding readers must use

	srcu_read_lock() and srcu_read_unlock(), and with the same

	srcu_struct.  The rules for the expedited RCU grace-period-wait

	primitives are the same as for their non-expedited counterparts.



	If the updater uses call_rcu_tasks() or synchronize_rcu_tasks(),

	then the readers must refrain from executing voluntary

	context switches, that is, from blocking.  If the updater uses

	call_rcu_tasks_trace() or synchronize_rcu_tasks_trace(), then

	the corresponding readers must use rcu_read_lock_trace() and

	rcu_read_unlock_trace().  If an updater uses call_rcu_tasks_rude()

	or synchronize_rcu_tasks_rude(), then the corresponding readers

	must use anything that disables interrupts.



	Mixing things up will result in confusion and broken kernels, and

	has even resulted in an exploitable security issue.  Therefore,

	when using non-obvious pairs of primitives, commenting is

	of course a must.  One example of non-obvious pairing is

	the XDP feature in networking, which calls BPF programs from

	network-driver NAPI (softirq) context.	BPF relies heavily on RCU

	protection for its data structures, but because the BPF program

	invocation happens entirely within a single local_bh_disable()

	section in a NAPI poll cycle, this usage is safe.  The reason

	that this usage is safe is that readers can use anything that

	disables BH when updaters use call_rcu() or synchronize_rcu().



8.	Although synchronize_rcu() is slower than is call_rcu(), it

	usually results in simpler code.  So, unless update performance is

Documentation/bpf/index.rst

+13 −0
Original line number Diff line number Diff line
@@ -12,6 +12,19 @@ BPF instruction-set. 
The Cilium project also maintains a `BPF and XDP Reference Guide`_

that goes into great technical depth about the BPF Architecture.



libbpf

======



Libbpf is a userspace library for loading and interacting with bpf programs.



.. toctree::

   :maxdepth: 1



   libbpf/libbpf

   libbpf/libbpf_api

   libbpf/libbpf_build

   libbpf/libbpf_naming_convention



BPF Type Format (BTF)

=====================

Documentation/bpf/libbpf/libbpf.rst

0 → 100644
+14 −0
Original line number Diff line number Diff line 
.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)



libbpf

======



This is documentation for libbpf, a userspace library for loading and

interacting with bpf programs.



All general BPF questions, including kernel functionality, libbpf APIs and

their application, should be sent to bpf@vger.kernel.org mailing list.

You can `subscribe <http://vger.kernel.org/vger-lists.html#bpf>`_ to the

mailing list search its `archive <https://lore.kernel.org/bpf/>`_.

Please search the archive before asking new questions. It very well might

be that this was already addressed or answered before.

Documentation/bpf/libbpf/libbpf_api.rst

0 → 100644
+27 −0
Original line number Diff line number Diff line 
.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)



API

===



This documentation is autogenerated from header files in libbpf, tools/lib/bpf



.. kernel-doc:: tools/lib/bpf/libbpf.h

   :internal:



.. kernel-doc:: tools/lib/bpf/bpf.h

   :internal:



.. kernel-doc:: tools/lib/bpf/btf.h

   :internal:



.. kernel-doc:: tools/lib/bpf/xsk.h

   :internal:



.. kernel-doc:: tools/lib/bpf/bpf_tracing.h

   :internal:



.. kernel-doc:: tools/lib/bpf/bpf_core_read.h

   :internal:



.. kernel-doc:: tools/lib/bpf/bpf_endian.h

   :internal:
 
 No newline at end of file

Documentation/bpf/libbpf/libbpf_build.rst

0 → 100644
+37 −0
Original line number Diff line number Diff line 
.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)



Building libbpf

===============



libelf and zlib are internal dependencies of libbpf and thus are required to link

against and must be installed on the system for applications to work.

pkg-config is used by default to find libelf, and the program called

can be overridden with PKG_CONFIG.



If using pkg-config at build time is not desired, it can be disabled by

setting NO_PKG_CONFIG=1 when calling make.



To build both static libbpf.a and shared libbpf.so:



.. code-block:: bash



    $ cd src

    $ make



To build only static libbpf.a library in directory build/ and install them

together with libbpf headers in a staging directory root/:



.. code-block:: bash



    $ cd src

    $ mkdir build root

    $ BUILD_STATIC_ONLY=y OBJDIR=build DESTDIR=root make install



To build both static libbpf.a and shared libbpf.so against a custom libelf

dependency installed in /build/root/ and install them together with libbpf

headers in a build directory /build/root/:



.. code-block:: bash



    $ cd src

    $ PKG_CONFIG_PATH=/build/root/lib64/pkgconfig DESTDIR=/build/root make
 
 No newline at end of file