aboutsummaryrefslogtreecommitdiffstats
path: root/sys/linux/bpf.txt.const
Commit message (Collapse)AuthorAgeFilesLines
* pkg/compiler: add consts to all files that mention themDmitry Vyukov2024-11-131-0/+3
| | | | | | | | | We already do this in most cases except for template structs (nlattr notably). Add consts that are used in template structs to all files that use them. This helps to avoid flakiness, and allows to replace descriptions files with other descriptions files without regenerating all const files. This also fixes check for presence of descriptions for sys/linux/auto.txt.json.
* sys/linux: describe new BTF typesPaul Chaignon2024-10-101-0/+4
| | | | | | | | | | | | | Describe four new BTF types introduced in commits [1, 2, 3, 4] upstream. Note BTF_KIND_TAG was later renamed to BTF_KIND_DECL_TAG. These four types are also described in the documentation at [5]. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b1828f0b04828 2 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b5ea834dde6b6 3 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c42d2fa4eeab 4 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6089fb325cf73 5 - https://docs.kernel.org/bpf/btf.html#btf-kind-float Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: fix linkage field of BTF_KIND_VAR typePaul Chaignon2024-10-101-0/+3
| | | | | | | | | | The linkage field of BTF type BTF_KIND_VAR isn't actually a boolean, but a flag. Given it can now take three different values [1], it doesn't match the boolean type and needs to be fixed. This commit defines it as a proper flags type. 1 - https://docs.kernel.org/bpf/btf.html#btf-kind-var Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: improve precision of BPF attach targetsPaul Chaignon2024-09-111-0/+18
| | | | | | | | | | | | | | | How the attach target field is interpreted depends on the program type [1], which itself depends on the attach type [2] (defined in attach_type_to_prog_type upstream). This commit encodes the same in syzkaller to make the attach target field more precise. Because attach_type_to_prog_type is a simple n to 1 mapping, we can encode it as defines. We can then use those defines in conditional fields for the different types of attach targets. 1 - https://elixir.bootlin.com/linux/v6.10.9/source/kernel/bpf/syscall.c#L4098 2 - https://elixir.bootlin.com/linux/v6.10.9/source/kernel/bpf/syscall.c#L3913 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: replace id_or_fd with more precise versionPaul Chaignon2024-09-111-0/+1
| | | | | | | | | | | | | The id_or_fd union was introduced before we had conditional fields to represent IDs or fds for BPF programs or links. The union was overapproximating those specific types. With conditional fields, we can now use information from other fields to determine precisely which type from the union is expected. For example, with BPF_PROG_ATTACH, if BPF_F_ID is the only flag, then the relative_fd field should be interpreted as a program ID. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: cover BPF tokensPaul Chaignon2024-09-091-0/+1
| | | | | | | | | | | | | | | | | | | The new BPF_TOKEN_CREATE bpf(2) command was introduced in commit [1] upstream. This command takes a BPF filesystem fd and returns a BPF token [2]. This token can then be passed to commands BPF_PROG_LOAD, BPF_MAP_CREATE, and BPF_BTF_LOAD and the kernel will use it to check if the operation is allowed. What operations a token allows is defined by the mount options of the BPF filesystem. No flags are currently supported for the BPF_TOKEN_CREATE command. The fd should point to the BPF filesystem, but we don't have a specific resource for this yet so just point to a generic fd. This command also doesn't add support for the new mount options. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=35f96de04127 2 - https://lwn.net/Articles/947173/ Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: update BPF constantsPaul Chaignon2024-09-091-0/+7
| | | | Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: run make extractAleksandr Nogikh2024-01-301-84/+2
| | | | | Split out deprecated descriptions from socket_netlink_route_sched.txt. Adjust outdated descriptions.
* sys/linux: add BPF_RB_* flags for ringbuf helpersPaul Chaignon2023-11-091-2/+4
| | | | | | | | | | | | | BPF helpers bpf_ringbuf_{discard,submit,output} take a set of flags. This commit describes those flags. The default is a zero value, but the kernel doesn't have a macro for that. Thus, "0" is simply added to the flag definition. Note bpf_ringbuf_reserve also has a flags argument, but it is currently unused on the kernel side. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe BPF helper bpf_ringbuf_outputPaul Chaignon2023-11-091-0/+1
| | | | | | | | | | | | | This helper has the prototype: bpf_ringbuf_output(void *ringbuf, void *data, u64 size, u64 flags) We need to prepare the second argument (R2) on the stack. We use an 8 bytes data value initialized to some random value on the stack and pointed to by R2. The third argument therefore needs to be 8 (for 8 bytes). Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe BPF helper call to bpf_ringbuf_queryPaul Chaignon2023-11-091-0/+1
| | | | | | | | This BPF helper has the prototype: bpf_ringbuf_query(void *ringbuf, u64 flags) Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe call to BPF helper bpf_ringbuf_discardPaul Chaignon2023-11-091-0/+1
| | | | | | | | Including this helper call in our descriptions is trivial since it takes the same arguments and returns the same (void) as the already described bpf_ringbuf_submit helper call. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe call to BPF helper bpf_ringbuf_submitPaul Chaignon2023-11-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This helper has the verifier prototype: .ret_type = RET_VOID, .arg1_type = ARG_PTR_TO_RINGBUF_MEM | OBJ_RELEASE, .arg2_type = ARG_ANYTHING, We therefore need to pass the pointer retrieved with bpf_ringbuf_reserve via R2. We saved that pointer to R9 so we can retrieve it from there. Since bpf_ringbuf_submit doesn't return anything, we need to write something in R0 before we exit the program. Our BPF program now looks like: u64 *e; e = bpf_ringbuf_reserve(&rb, sizeof(*e), 0); [...] bpf_ringbuf_submit(e, 0); return 0; It will still fail, but with EACCES instead of EINVAL, due to the following verifier error: 0: R1=ctx(off=0,imm=0) R10=fp0 0: (18) r0 = 0x0 ; R0_w=0 2: (18) r1 = 0xffff984f66f93600 ; R1_w=map_ptr(off=0,ks=0,vs=0,imm=0) 4: (b7) r2 = 20 ; R2_w=20 5: (b7) r3 = 0 ; R3_w=0 6: (85) call bpf_ringbuf_reserve#131 ; R0_w=ringbuf_mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) refs=2 7: (bf) r9 = r0 ; R0_w=ringbuf_mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) R9_w=ringbuf_mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) refs=2 8: (bf) r1 = r9 ; R1_w=ringbuf_mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) R9_w=ringbuf_mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) refs=2 9: (b7) r2 = 0 ; R2_w=0 refs=2 10: (85) call bpf_ringbuf_submit#132 R1 type=ringbuf_mem_or_null expected=ringbuf_mem In short, we didn't check that the pointer returned by bpf_ringbug_reserve isn't null. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe call to BPF helper bpf_ringbuf_reservePaul Chaignon2023-11-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Describe a full call to bpf_ringbuf_reserve, using the map type created in the previous commit. The test corresponds to this simple line: u64 *e; e = bpf_ringbuf_reserve(&rb, sizeof(*e), 0); [...] return e; The pointer returned by bpf_ringbuf_reserve is kept in R9. The goal is to keep it around so we can use it in other instructions later; several other helpers take a pointer to ringbuf data as argument. There's of course a risk that some instruction in between will clobber R9, but I don't know another way. R9 is at least safe for calls (only R1--R5 get clobbered). We expect the program loading to fail with EINVAL because we never release the reference to the ringbuf data. The verifier will therefore reject the program with: 0: R1=ctx(off=0,imm=0) R10=fp0 0: (18) r0 = 0x0 ; R0_w=0 2: (18) r1 = 0xffff984e4b55da00 ; R1_w=map_ptr(off=0,ks=0,vs=0,imm=0) 4: (b7) r2 = 20 ; R2_w=20 5: (b7) r3 = 0 ; R3_w=0 6: (85) call bpf_ringbuf_reserve#131 ; R0_w=ringbuf_mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) refs=2 7: (bf) r9 = r0 ; R0_w=ringbuf_mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) R9_w=ringbuf_mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) refs=2 8: (95) exit Unreleased reference id=2 alloc_insn=6 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe call to bpf_tail_call helperPaul Chaignon2023-11-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bpf_tail_call helper has the following prototype. bpf_tail_call(void *ctx, struct bpf_map *prog_array_map, u32 index) R2 should therefore hold a pointer to a tail call map (aka, prog array map). That tail call map should be updated such that index points to another BPF program. In our case, index is hardcoded to 0. Finally, R1 should hold a pointer to the context. That is always true at the start of BPF programs so we don't change R1. If syzkaller generates other BPF instructions between the start of the program and the bpf_tail_call helper call, they might clobber the R1 register. That seems unlikely to happen in practice and it's also hard to prevent it anyway. To load the map fd into R2, we need to templatize bpf_insn_map_fd such that we can use it with a specific register and map fd. There's one special case here: we need to explicitly set R0 to 0 after the helper call because this helper has the following verifier prototype: .ret_type = RET_VOID, .arg1_type = ARG_PTR_TO_CTX, .arg2_type = ARG_CONST_MAP_PTR, .arg3_type = ARG_ANYTHING, Given the return verifier type is RET_VOID, if R0 isn't set explicitly, the verifier will complain with "R0 !read_ok" when we exit. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: update BPF constantsPaul Chaignon2023-11-061-0/+7
| | | | | | | | These new constants were introduced in commits [1, 2] upstream. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=859051dd165ec 2 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=35dfaad7188cd Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: support new BPF opcode BPF_MEMSXPaul Chaignon2023-10-231-1/+2
| | | | | | | | | | | | | | | Commit [1] upstream added support for new sign-extended load instructions. Those instructions rely on a new mode, BPF_MEMSX, for the opcode. This commit adds that mode to the BPF description. Note that several other instructions were defined at the same type, but our BPF instruction descriptions are currently generic enough that no other changes are needed. In the future, we may want to make those descriptions more specific to avoid wasting fuzzing time on unsupported instruction formats. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1f9a1ea821ff Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe full call to bpf_snprintf helperPaul Chaignon2023-10-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit describes the full snippet of BPF bytecode required to successfully call the bpf_snprintf helper. That helper has the following prototype: long bpf_snprintf(char *str, u32 str_size, const char *fmt, u64 *data, u32 data_len) with the following verifier types: .arg1_type = ARG_PTR_TO_MEM_OR_NULL, .arg2_type = ARG_CONST_SIZE_OR_ZERO, .arg3_type = ARG_PTR_TO_CONST_STR, .arg4_type = ARG_PTR_TO_MEM | PTR_MAYBE_NULL | MEM_RDONLY, .arg5_type = ARG_CONST_SIZE_OR_ZERO, The first and fourth arguments can point to nulled buffers on the stack. The second and fifth arguments contain the sizes of those buffers. Finally, the third argument must point to a map holding a constant string; we can use the type introduced in the previous commit for that. The corresponding eBPF bytecode is kept in comment as that is much easier to parse for anyone familiar with the bytecode. In addition to the test case introduced in the next commit, this description was tested by running syzkaller with a focus on the necessary bpf syscalls. Specifically, syscalls bpf$MAP_CREATE_CONST_STR, bpf$MAP_UPDATE_CONST_STR, bpf$BPF_MAP_CONST_STR_FREEZE, bpf$PROG_LOAD, and bpf$BPF_PROG_TEST_RUN were executed on 16 VMs (with two logical cores each). Syzkaller was then able to reach the formatter parsing logic of function bpf_bprintf_prepare [1], which bpf_snprintf calls. 1 - https://github.com/torvalds/linux/blob/v6.5/kernel/bpf/helpers.c#L875 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe full call to bpf_trace_printk helperPaul Chaignon2023-10-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit describes the full snippet of BPF bytecode necessary to successfully call the bpf_trace_printk helper. That helper has the following prototype: long bpf_trace_printk(const char *fmt, u32 fmt_size, ...) We thus need to initialize the fmt string on the stack, then prepare the arguments (pointer to the stack & size), before actually calling the helper. To that end, we rely on previously defined templates to express the specific instructions we need (e.g., init register with imm, perform ALU operation on register with imm). The corresponding eBPF bytecode is kept in comment as that is much easier to parse for anyone familiar with the bytecode. In addition to the test case introduced in the next commit, this new description was tested by focusing fuzzing on bpf_trace_printk. That is, a new syscall description PROG_LOAD_FOCUS was added to cover only programs with bpf_trace_printk. Syzkaller was then executed on 16 VMs (2 logical cores each) with only the bpf$PROG_LOAD_FOCUS and bpf$BPF_PROG_TEST_RUN syscalls enabled. It was able to reach the definition of this helper [1] within a few minutes. 1 - https://github.com/torvalds/linux/blob/v6.5/kernel/trace/bpf_trace.c#L375 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: templatize ldst, alu, and call_helper BPF instructionsPaul Chaignon2023-10-161-0/+2
| | | | | | | | | | | | | | This commit templatizes the bpf_insn_ldst, bpf_insn_alu, bpf_insn_call_helper, bpf_insn_map_value BPF instruction descriptions. This will allow subsequent commits to define new, more specific descriptions of those instructions in addition to the existing generic descriptions. For example, a subsequent commit will use the new bpf_insn_call_helper_t template to define a call to helper bpf_snprintf specifically. This commit doesn't have any functional changes. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: cover multi-uprobes for BPF_LINK_CREATEPaul Chaignon2023-09-131-0/+1
| | | | | | | | | | | | | | | Upstream, commit [1] added support for multi-uprobe links, to speed up the attachment of uprobes BPF programs by attaching in batches. This commit covers the same in syzkaller. Field path is a path to the binary, offsets are the offsets to attach to in the binary, and cnt is the number of uprobes to attach to. Field ref_ctr_offsets is a bit trickier as it can point to an array of reference counters; I limited those to 0--5 as they are not expected to be large. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=89ae89f53d2011435 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: cover BPF links for BPF netfilter programsPaul Chaignon2023-09-131-0/+3
| | | | | | | | | Commit [1] upstream added support for attaching BPF netfilter programs through the BPF_LINK_CREATE bpf(2) command. This commit adds the syzkaller counterpart. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=84601d6ee68ae820d Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: cover multi-kprobes in BPF_LINK_CREATEPaul Chaignon2023-09-131-0/+1
| | | | | | | | | | | | | | Commit [1] upstream added support for multi-kprobes to BPF link, to allow attaching many kprobes BPF programs at once. In doing so, the BPF_LINK_CREATE command was extended with attachment information for kprobes. This commit covers this in syzkaller's description. We have two cases to cover: kprobes are either attached by symbols (resolved by the kernel) or directly by kernel addresses. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0dcac272540613d41 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: cover BPF iterators support in BPF_LINK_CREATEPaul Chaignon2023-09-131-0/+4
| | | | | | | | | | | | | | | | Commit [1] upstream extended the bpf(2) BPF_LINK_CREATE command with optional fields for BPF iterators. The extra field is a pointer to a bpf_iter_link_info struct and its size. Commits [2, 3] upstream latter extended the bpf_iter_link_info struct to cover cgroup and task iterators. This commit extends the syzkaller description of BPF_LINK_CREATE to cover the above. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5e7b30205cef80f6b 2 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4ccaf58a8472123a 3 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f0d74c4da1f060d2a Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: update BPF constantsPaul Chaignon2023-09-111-0/+6
| | | | Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: support O_PATH fds in BPF_OBJ_* cmdsPaul Chaignon2023-08-251-0/+1
| | | | | | | | | | | | Commit [1] upstream added support for O_PATH fds in BPF_OBJ_* commands. This commit implements the same support in syzkaller. The flag BPF_F_PATH_FD must be set when passing an O_PATH to the BPF_OBJ_* commands. We therefore declare generic and O_PATH-specific variants of the existing BPF_OBJ structs. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb8edce2807 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: support CO-RE info in PROG_LOAD commandPaul Chaignon2023-08-251-0/+14
| | | | | | | | | | Commit [1] upstream added support via the bpf(2) PROG_LOAD command to load BTF CO-RE relocation data. This commit adds basic support for loading the same data in syzkaller. As usual with BTF, we are pretty limited in what we can efficiently describe :-( 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fbd94c7afcf9 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: update BPF constantsPaul Chaignon2023-08-251-0/+11
| | | | Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: update const filesDmitry Vyukov2022-11-131-1/+1
| | | | Update const files on next-20221031.
* sys/linux: regenerate constsDmitry Vyukov2022-08-101-1/+1
| | | | Regenerate consts on upstream 4e23eeebb2e57f5a28b36221aa776b5a1122dde5.
* sys/linux: update constsDmitry Vyukov2022-06-021-1/+1
| | | | | Update const files on the latest upstream commit d1dc87763f406d4e67caf16dbe438a5647692395
* sys/linux: make bpf_link_create_arg a templateDmitry Vyukov2022-04-271-0/+5
| | | | | | Make bpf_link_create_arg a template so that it's possible to create more specialized versions. Add a specialized version for XDP links. First, they need a special program type, plus a special attach type and target fd is not an fd, but rather ifindex.
* sys/linux: regenerate .const filesDmitry Vyukov2022-04-251-1/+1
| | | | | Regenerated on the current upstream HEAD: 22da5264abf497a10a4ed629f07f4ba28a7ed5eb
* sys/linux: regenerate const filesDmitry Vyukov2022-03-161-1/+1
| | | | | Regenerate on latest upstream commit 56e337f2cf1326323844927a04e9dbce9a244835.
* sys/linux: update const filesDmitry Vyukov2022-01-271-1/+1
| | | | Regenerate const files on next-20220127.
* sys/linux: fix bugs pointed out by syz-checkDmitry Vyukov2022-01-131-1/+1
| | | | Update #590
* sys/linux: support BPF calls to kernel functionsPaul Chaignon2021-12-211-0/+1
| | | | | | | | | | | | | | | Commit [1] upstream introduced support for BPF calls to kernel functions, via a new call instruction BPF_PSEUDO_KFUNC_CALL. In this new instruction, the immediate value is the BTF ID of the function to call in the kernel. This commit introduces basic support for this new instruction in syzkaller. The immediate value will point to a BTF ID, but a fair amount of additional work would be required to ensure that BTF ID is actually pointing to a kernel function. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e6ac2450d6dee Signed-off-by: Paul Chaignon <paul@isovalent.com>
* sys/linux: support callback BPF functionsPaul Chaignon2021-12-211-0/+1
| | | | | | | | | | | | | | | | | | Commit [1] upstream introduced a new BPF helper, bpf_for_each_map_elem, which comes with callback functions (BPF programs). The callback function's address is provided via a 64-bit IMM load instruction where the first 32-bit of the immediate value are the offset from the current instruction to the start of the callback function. The 64-bit value is then rewritten into the address of the callback function. Callback BPF functions are similar to BPF_PSEUDO_CALL functions, except the offset to the function is converted into an address to be passed to a BPF helper. The same workaround is thus used to encode the offset in syzkaller, given we can't currently limit the offset to the program size. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=69c087ba6225b Signed-off-by: Paul Chaignon <paul@isovalent.com>
* sys/linux: support map fd arraysPaul Chaignon2021-12-211-0/+2
| | | | | | | | | | | | | | | Commit [1] upstream introduced a new way to reference BPF maps in eBPF instructions. An array of BPF map fds is passed at program load time. Instructions can then reference fds in this array instead of carrying the fds directly. The goal is to allow BPF instructions to be immutable after compilation. Since we don't yet have a good way to reference indexes in an array, we define a new type map_fd_id for that purpose, with indexes between 0 and 16 only. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=387544bfa291 Signed-off-by: Paul Chaignon <paul@isovalent.com>
* sys/linux: update BPF constantsPaul Chaignon2021-12-211-0/+6
| | | | Signed-off-by: Paul Chaignon <paul@isovalent.com>
* sys/linux: fix and regenerate consts on the latest kenrelDmitry Vyukov2021-11-121-1/+1
| | | | Fix missed includes and renamed constants and regenerate const files on 89d714ab60.
* sys/linux: regenerate consts, remove ipxDmitry Vyukov2021-10-131-1/+1
| | | | | | Regenerate const files on the latest upstream tree. Remove IPX support since it was removed from the kernel in 7a2e838d28 ("staging: ipx: delete it from the tree").
* sys/linux: regen .const files on v5.14Dmitry Vyukov2021-09-161-1/+1
|
* sys/linux: add fq_pie description for netlink_route_schedMara Mihali2021-05-261-1/+1
|
* sys/linux: add file_handle descriptionsDmitry Vyukov2021-04-131-1/+1
|
* sys/linux: update constsDmitry Vyukov2021-03-021-1/+1
| | | | | Update consts on upstream 7a7fd0de4a9804299793e564a555a49c1fc924cb. Remove termiox ioctls, they were removed in commit e0efb3168d34.
* sys/linux: update BPF constantsPaul Chaignon2021-01-051-1/+2
| | | | Signed-off-by: Paul Chaignon <paul@cilium.io>
* sys/linux: update BPF_PROG_TEST_RUN's fieldsPaul Chaignon2020-10-261-0/+1
| | | | | | | These new fields were introduced in commit 1b4d60e ("bpf: Enable BPF_PROG_TEST_RUN for raw_tracepoint") upstream. Signed-off-by: Paul Chaignon <paul@cilium.io>
* sys/linux: update BPF constantsPaul Chaignon2020-10-261-0/+9
| | | | Signed-off-by: Paul Chaignon <paul@cilium.io>
* sys/linux: add PSEUDO_BTF_ID ld_imm BPF instructionPaul Chaignon2020-10-261-0/+1
| | | | | | | This new ld_imm instruction was introduced in commit 4976b71 ("bpf: Introduce pseudo_btf_id") upstream. Signed-off-by: Paul Chaignon <paul@cilium.io>
generated by ggit (джигит) mrf-deployment (git 2.46.0) at 2026-03-11 21:11:34 +0000