kernel/linux.git/Documentation/bpf, branch v6.19.11

docs: bpf: map_array: Specify BPF_MAP_TYPE_PERCPU_ARRAY value size limit

2025-11-25T22:32:00+00:00

Specify value size limit for BPF_MAP_TYPE_PERCPU_ARRAY which is PCPU_MIN_UNIT_SIZE (32 kb). In percpu allocator (mm: percpu), any request with a size greater than PCPU_MIN_UNIT_SIZE is rejected. Signed-off-by: Alex Tran Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20251115063531.2302903-1-alex.t.tran@gmail.com

docs/bpf: Add missing BPF k/uprobe program types to docs

2025-11-04T18:24:43+00:00

Update the table of program types in the libbpf docs with the missing k/uprobe multi and session program types. Signed-off-by: Donald Hunter Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20251029180932.98038-1-donald.hunter@gmail.com

bpf: disable and remove registers chain based liveness

2025-09-19T16:27:23+00:00

Remove register chain based liveness tracking: - struct bpf_reg_state->{parent,live} fields are no longer needed; - REG_LIVE_WRITTEN marks are superseded by bpf_mark_stack_write() calls; - mark_reg_read() calls are superseded by bpf_mark_stack_read(); - log.c:print_liveness() is superseded by logging in liveness.c; - propagate_liveness() is superseded by bpf_update_live_stack(); - no need to establish register chains in is_state_visited() anymore; - fix a bunch of tests expecting "_w" suffixes in verifier log messages. Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20250918-callchain-sensitive-liveness-v3-9-c3cd27bacc60@gmail.com Signed-off-by: Alexei Starovoitov

bpf: Enforce RCU protection for KF_RCU_PROTECTED

2025-09-18T22:36:17+00:00

Currently, KF_RCU_PROTECTED only applies to iterator APIs and that too in a convoluted fashion: the presence of this flag on the kfunc is used to set MEM_RCU in iterator type, and the lack of RCU protection results in an error only later, once next() or destroy() methods are invoked on the iterator. While there is no bug, this is certainly a bit unintuitive, and makes the enforcement of the flag iterator specific. In the interest of making this flag useful for other upcoming kfuncs, e.g. scx_bpf_cpu_curr() [0][1], add enforcement for invoking the kfunc in an RCU critical section in general. This would also mean that iterator APIs using KF_RCU_PROTECTED will error out earlier, instead of throwing an error for lack of RCU CS protection when next() or destroy() methods are invoked. In addition to this, if the kfuncs tagged KF_RCU_PROTECTED return a pointer value, ensure that this pointer value is only usable in an RCU critical section. There might be edge cases where the return value is special and doesn't need to imply MEM_RCU semantics, but in general, the assumption should hold for the majority of kfuncs, and we can revisit things if necessary later. [0]: https://lore.kernel.org/all/20250903212311.369697-3-christian.loehle@arm.com [1]: https://lore.kernel.org/all/20250909195709.92669-1-arighi@nvidia.com Tested-by: Andrea Righi Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20250917032755.4068726-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov

Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf after rc3

2025-06-26T16:49:39+00:00

Cross-merge BPF, perf and other fixes after downstream PRs. It restores BPF CI to green after critical fix commit bc4394e5e79c ("perf: Fix the throttle error of some clock events") No conflicts. Signed-off-by: Alexei Starovoitov

bpf: Adjust free target to avoid global starvation of LRU map

2025-06-19T01:50:14+00:00

BPF_MAP_TYPE_LRU_HASH can recycle most recent elements well before the map is full, due to percpu reservations and force shrink before neighbor stealing. Once a CPU is unable to borrow from the global map, it will once steal one elem from a neighbor and after that each time flush this one element to the global list and immediately recycle it. Batch value LOCAL_FREE_TARGET (128) will exhaust a 10K element map with 79 CPUs. CPU 79 will observe this behavior even while its neighbors hold 78 * 127 + 1 * 15 == 9921 free elements (99%). CPUs need not be active concurrently. The issue can appear with affinity migration, e.g., irqbalance. Each CPU can reserve and then hold onto its 128 elements indefinitely. Avoid global list exhaustion by limiting aggregate percpu caches to half of map size, by adjusting LOCAL_FREE_TARGET based on cpu count. This change has no effect on sufficiently large tables. Similar to LOCAL_NR_SCANS and lru->nr_scans, introduce a map variable lru->free_target. The extra field fits in a hole in struct bpf_lru. The cacheline is already warm where read in the hot path. The field is only accessed with the lru lock held. Tested-by: Anton Protopopov Signed-off-by: Willem de Bruijn Acked-by: Stanislav Fomichev Link: https://lore.kernel.org/r/20250618215803.3587312-1-willemdebruijn.kernel@gmail.com Signed-off-by: Alexei Starovoitov

docs/bpf: Default cpu version changed from v1 to v3 in llvm 20

2025-06-12T23:52:44+00:00

The default cpu version is changed from v1 to v3 in llvm version 20. See [1] for more detailed reasoning. Update bpf_devel_QA.rst so developers can find such information easily. [1] https://github.com/llvm/llvm-project/pull/107008 Signed-off-by: Yonghong Song Link: https://lore.kernel.org/r/20250612043049.2411989-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov

bpf, doc: Improve wording of docs

2025-06-11T19:30:41+00:00

The phrase "dividing -1" is one I find confusing. E.g., "INT_MIN dividing -1" sounds like "-1 / INT_MIN" rather than the inverse. "divided by" instead of "dividing" assuming the inverse is meant. Signed-off-by: Eslam Khafagy Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20250607222434.227890-1-eslam.medhat1993@gmail.com Signed-off-by: Alexei Starovoitov

Documentation: Fix spelling mistake.

2025-06-07T02:22:36+00:00

Fix typo "desination => destination" in file Documentation/bpf/standardization/instruction-set.rst Signed-off-by: Eslam Khafagy Acked-by: Dave Thaler Acked-by: David Vernet Link: https://lore.kernel.org/r/20250606100511.368450-1-eslam.medhat1993@gmail.com Signed-off-by: Alexei Starovoitov

bpf: Add support for __prog argument suffix to pass in prog->aux

2025-05-14T01:47:54+00:00

Instead of hardcoding the list of kfuncs that need prog->aux passed to them with a combination of fixup_kfunc_call adjustment + __ign suffix, combine both in __prog suffix, which ignores the argument passed in, and fixes it up to the prog->aux. This allows kfuncs to have the prog->aux passed into them without having to touch the verifier. Cc: Tejun Heo Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20250513142812.1021591-1-memxor@gmail.com Signed-off-by: Alexei Starovoitov