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. ====================
Showing the changes to include/uapi/linux (1 of 122 files). Show all
Unified · Split
| @@ -260,6 +260,24 @@ enum bpf_attach_type { · 259 unmodified lines | ||
| 260 | 260 | */ |
| 261 | 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 | 281 | /* When BPF ldimm64's insn[0].src_reg != 0 then this can have |
| 264 | 282 | * two extensions: |
| 265 | 283 | * |
| @@ -2672,6 +2690,20 @@ union bpf_attr { · 2406 unmodified lines | ||
| 2672 | 2690 | * 0 on success. |
| 2673 | 2691 | * |
| 2674 | 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 | 2708 | #define __BPF_FUNC_MAPPER(FN) \ |
| 2677 | 2709 | FN(unspec), \ |
| @@ -2782,7 +2814,8 @@ union bpf_attr { · 104 unmodified lines | ||
| 2782 | 2814 | FN(strtol), \ |
| 2783 | 2815 | FN(strtoul), \ |
| 2784 | 2816 | FN(sk_storage_get), \ |
| 2785 | − FN(sk_storage_delete), | |
| 2817 | + FN(sk_storage_delete), \ | |
| 2818 | + FN(send_signal), | |
| 2786 | 2819 | |
| 2787 | 2820 | /* integer value in 'imm' field of BPF_CALL instruction selects which helper |
| 2788 | 2821 | * function eBPF program intends to call |