History

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

Alexei Starovoitov says: ==================== pull-request: bpf-next 2019-05-31 The following pull-request contains BPF updates for your *net-next* tree. Lots of exciting new features in the first PR of this developement cycle! The main changes are: 1) misc verifier improvements, from Alexei. 2) bpftool can now convert btf to valid C, from Andrii. 3) verifier can insert explicit ZEXT insn when requested by 32-bit JITs. This feature greatly improves BPF speed on 32-bit architectures. From Jiong. 4) cgroups will now auto-detach bpf programs. This fixes issue of thousands bpf programs got stuck in dying cgroups. From Roman. 5) new bpf_send_signal() helper, from Yonghong. 6) cgroup inet skb programs can signal CN to the stack, from Lawrence. 7) miscellaneous cleanups, from many developers. ====================

David S. Miller committed 7 years ago

Commit 0462eaa2 parents 33aae28 cd53850122 files · +6430 −1013Browse files

Showing the changes to include/uapi/linux (1 of 122 files). Show all

Unified · Split

include/uapi/linux/bpf.h+34−1
@@ -260,6 +260,24 @@ enum bpf_attach_type { · 259 unmodified lines
260 */260 */
261#define BPF_F_ANY_ALIGNMENT (1U << 1)261#define BPF_F_ANY_ALIGNMENT (1U << 1)
262 262
263/* BPF_F_TEST_RND_HI32 is used in BPF_PROG_LOAD command for testing purpose.
264 * Verifier does sub-register def/use analysis and identifies instructions whose
265 * def only matters for low 32-bit, high 32-bit is never referenced later
266 * through implicit zero extension. Therefore verifier notifies JIT back-ends
267 * that it is safe to ignore clearing high 32-bit for these instructions. This
268 * saves some back-ends a lot of code-gen. However such optimization is not
269 * necessary on some arches, for example x86_64, arm64 etc, whose JIT back-ends
270 * hence hasn't used verifier's analysis result. But, we really want to have a
271 * way to be able to verify the correctness of the described optimization on
272 * x86_64 on which testsuites are frequently exercised.
273 *
274 * So, this flag is introduced. Once it is set, verifier will randomize high
275 * 32-bit for those instructions who has been identified as safe to ignore them.
276 * Then, if verifier is not doing correct analysis, such randomization will
277 * regress tests to expose bugs.
278 */
279#define BPF_F_TEST_RND_HI32 (1U << 2)
280
263/* When BPF ldimm64's insn[0].src_reg != 0 then this can have281/* When BPF ldimm64's insn[0].src_reg != 0 then this can have
264 * two extensions:282 * two extensions:
265 *283 *
@@ -2672,6 +2690,20 @@ union bpf_attr { · 2406 unmodified lines
2672 * 0 on success.2690 * 0 on success.
2673 *2691 *
2674 * **-ENOENT** if the bpf-local-storage cannot be found.2692 * **-ENOENT** if the bpf-local-storage cannot be found.
2693 *
2694 * int bpf_send_signal(u32 sig)
2695 * Description
2696 * Send signal *sig* to the current task.
2697 * Return
2698 * 0 on success or successfully queued.
2699 *
2700 * **-EBUSY** if work queue under nmi is full.
2701 *
2702 * **-EINVAL** if *sig* is invalid.
2703 *
2704 * **-EPERM** if no permission to send the *sig*.
2705 *
2706 * **-EAGAIN** if bpf program can try again.
2675 */2707 */
2676#define __BPF_FUNC_MAPPER(FN) \2708#define __BPF_FUNC_MAPPER(FN) \
2677 FN(unspec), \2709 FN(unspec), \
@@ -2782,7 +2814,8 @@ union bpf_attr { · 104 unmodified lines
2782 FN(strtol), \2814 FN(strtol), \
2783 FN(strtoul), \2815 FN(strtoul), \
2784 FN(sk_storage_get), \2816 FN(sk_storage_get), \
2785 FN(sk_storage_delete),2817 FN(sk_storage_delete), \
2818 FN(send_signal),
2786 2819
2787/* integer value in 'imm' field of BPF_CALL instruction selects which helper2820/* integer value in 'imm' field of BPF_CALL instruction selects which helper
2788 * function eBPF program intends to call2821 * function eBPF program intends to call