mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-10 20:48:12 +00:00
No description
- C 96.8%
- Assembly 0.9%
- Rust 0.7%
- Shell 0.6%
- Python 0.5%
- Other 0.3%
ce7c9f6c59
Kumar Kartikeya Dwivedi says: ==================== Redesign Verification Errors TL;DR: This set reworks verifier error messages to include source and instruction annotations, together with more causal context, making failures easier to understand and more actionable when debugging and repairing BPF programs. Changelog: ---------- v4 -> v5 v4: https://lore.kernel.org/bpf/20260812233326.3575958-1-memxor@gmail.com * Defer Verifier Limit reports and the dependent call-chain allocation guards to follow-up work, reducing the series from 16 to 14 patches. (Eduard) * Make kfunc-name disassembly read-only before module-kfunc metadata is resolved, retain instruction context without usable source metadata, consolidate its fallback, and restrict source discovery to the containing subprogram. (Eduard, Sashiko) * Retain the newest diagnostic history in a bounded 64 MiB rotating buffer, use absolute logical positions across verifier path switches, report evicted shared history, and grow storage geometrically. (Eduard) * Complete active-path history for BPF_LD_IMM64 and atomic fetches, call clobbers and returns, outgoing stack arguments, legacy packet loads, and RCU pointer transitions. (Eduard, Sashiko) * Preserve causal lineage across equal snapshots, nullable pointer-cast branches, and repeated same-depth function invocations using unique diagnostic frame identities. Bound each rendered causal path to the oldest and newest 32 matching events with an omission summary. (Eduard) * Harden diagnostics for malformed release-kfunc signatures, fixed-size argument ranges, and dynptr, iterator, memory-size, and required-RCU failures by reporting the actual offending type or invariant. (Eduard, Sashiko) * Remove unrelated formatting and cross-patch churn, dead or single-use helpers and filter paths, and align helper placement, includes, and commit descriptions with the patches that first need them. (Eduard) v3 -> v4 v3: https://lore.kernel.org/bpf/20260713153910.2556007-1-memxor@gmail.com * Introduce helpers with their first callers and add printf annotations. (Eduard, Sashiko) * Remove "report" from diagnostic function names. (Sashiko) * Reuse bpf_linfo_source and seq_buf, simplify internal names, and use shared formatting storage. (Eduard) * Use compact common event fields and record branches at successor entry. (Eduard) * Bound event storage at 1 MiB, use kvrealloc(), and drop events non-fatally. (Eduard, Sashiko) * Restore diagnostic history only for activated queued states, preserving the active failure trace during cleanup. (Eduard, Sashiko) * Record register changes through begin/end and scrub helpers, deriving targets and origins without caller-saved snapshots. (Eduard) * Store lineage marks on events and rewind shared formatting storage after rendering each event. (Eduard) * Record iterator return values before snapshotting alternate paths. (Sashiko) * Use the current verifier instruction for global-subprogram dynptr errors. (Sashiko) * Use the supplied call name for nullable global-subprogram arguments. (Sashiko) * Describe global calls under locks as a verifier restriction rather than a sleepability failure. (Sashiko) * Keep diagnostic strings unsplit and put long call openings on their own line. (Eduard) * Keep kfunc metadata zeroed before early fetch and allowability failures. (Sashiko) * Drop the Verifier Internal Error report patch. (Eduard) * Distinguish never-initialized registers from invalidated registers. (local review) * Preserve the legacy different-lock verifier message. (local review) * Preserve nullable type qualifiers and stable mismatch formatting. (local review) * Mark truncated call chains with an ellipsis. (local review) v2 -> v3 v2: https://lore.kernel.org/bpf/20260619205934.1312876-1-memxor@gmail.com * Address various comments from Eduard and Sashiko. * Move instruction context from a separate gutter into a new section following source context, since surrounding source lines and BPF instructions do not map one-to-one. * Fix active-path branch reconstruction when switching to queued states, and expand register histories to follow value lineage across spills, fills, stack reads, helper/kfunc clobbers, and dynptr invalidation. * Misc improvements and refinements. v1 -> v2 v1: https://lore.kernel.org/bpf/20260605063412.974640-1-memxor@gmail.com * Reworked diagnostic history from per-verifier-state log to active path log with positions saved and reset when verifier search backtracks. (Eduard) * Moved reusable diagnostic formatting storage into struct bpf_diag under struct bpf_verifier_env, and removed large per-report scratch buffers from verifier stack frames. (Eduard) * Added stack-slot events so diagnostics follow ordinary stack spill/fill value flow and invalidations in register-scoped histories. (Eduard) * Reused existing source and BTF formatting helpers for diagnostics, including bpf_get_linfo_file_line() and btf_type_snprintf_show_name(). (Eduard) * Fixed diagnostic edge cases around signed offset text, BPF_MAX_VAR_OFF reporting, negative-offset clamping, poisoned stack reads, and borrowed-reference invalidations. (Eduard) * Fixed various miscellaneous diagnostic bugs. (Sashiko) * Misc improvements and refinements. --- Motivation ~~~~~~~~~~ The verifier log is the primary interface through which the verifier communicates to the user its verdict on whether a program was accepted or rejected. To aid the debugging of rejection decisions, the verifier also reports the symbolic state of the program at each instruction, across every explored path of the BPF program. Such detailed information is critical to introspect the correctness of verification decisions, and provide insight into why a given program may have failed to load in the kernel. A constant pain point in the BPF ecosystem throughout the years has been the difficulty of debugging verification errors. The human-readable error messages produced in response to a failure in satisfying safety-related constraints are often terse, context-dependent, or insufficient for understanding why a given error may have happened. Users must fall back to the verbose instruction-by-instruction breakdown of how the symbolic state evolved to surface the root cause. For programs with a huge log volume due to high verification complexity, such logs quickly become inscrutable. All of this has made life difficult for users lacking an understanding of how the verifier works, and the various heuristics and idiosyncrasies used by it. In some cases, even seasoned BPF experts spend significant time reverse engineering why a program may have failed, and have to reach into the verifier's source code to form a complete picture of the verification process. Such a steep learning curve and cognitive burden also hurts the speed of BPF development, as the verifier sits right in the middle of the user's iteration loop while they make use of BPF to solve any given problem. Expertise in debugging verifier errors does not scale in terms of teams deploying these programs in production across a diverse set of kernels. Overall, this leads to a poorer developer experience, causes visible user dissatisfaction, and remains a drag on wider BPF adoption. With some of the more recent developments where users increasingly leverage AI tooling [0] to author their code, this bottleneck becomes even more critical to address, since it throttles the much faster iteration loop of AI agents. [0]: https://lwn.net/Articles/1075067 Approach ~~~~~~~~ This series starts moving selected failures from terse terminal messages toward diagnostics that carry the relevant context for a verification failure. The existing verbose log remains the low-level trace. For selected failures, the new report is emitted after this trace and answers the immediate debugging questions: - what verifier rule failed, - why the current state does not satisfy it, - where the failing instruction maps to source, - which earlier branch or state event made this path fail, - what kind of source change would satisfy the verifier. The series adds a text-only diagnostics framework under kernel/bpf and uses it to augment selected verifier errors. Existing verbose(env, ...) messages are kept, so current selftest expectations and existing log consumers continue to see the legacy text. The new report has a uniform outer shape: Verification failed: <category>: <problem> Reason: exact reason for the verification failure, with details At: source and instruction annotation Causal path: compressed branch and verifier-state events relevant for debugging Suggestion: speculation on potential fixes to repair the program The outer shape is shared, but report construction is category-specific. The categories are intentionally broad and reviewable. This revision covers representative cases in Register Type Safety, Memory Safety, Resource Lifetime Safety, Call Type Safety, Execution Context Safety, Program Structure and Policy. It does not attempt to convert every verbose(env, ...) site for now. Additional verbose-only errors can be moved into the same framework incrementally. The following excerpts are copied from this current run on this branch: ./test_progs -j1 \ -a cpumask/test_populate_invalid_destination,\ cpumask/test_alloc_no_release,\ verifier_helper_value_access/via_variable_no_max_check_1,\ verifier_sock/invalidate_pkt_pointers_from_global_func \ -vv They show the old terminal error and the exact new diagnostic report, including the source and instruction annotations. Call Type Safety, cpumask/test_populate_invalid_destination: Legacy: R1 type=scalar expected=fp Diagnostic: Verification failed: Call Type Safety: Invalid call argument Reason: The first argument (R1) to bpf_cpumask_populate does not satisfy the verifier contract: the kfunc expects 24 bytes of memory for (struct bpf_cpumask), but it is an integer scalar and not verifier-known memory. At: test_populate_invalid_destination @ cpumask_failure.c:234:8 Source context: 232 | ... 233 | ... >>> 234 | ret = bpf_cpumask_populate(invalid, &bits, sizeof(bits)); | ^-- error: invalid first argument (R1) for bpf_cpumask_populate 235 | if (!ret) 236 | err = 2; Instruction context: 2 | (b7) r1 = |
History
|
|
|---|---|---|
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| io_uring | ||
| ipc | ||
| kernel | ||
| lib | ||
| LICENSES | ||
| mm | ||
| net | ||
| rust | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .clippy.toml | ||
| .cocciconfig | ||
| .editorconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .pylintrc | ||
| .rustfmt.toml | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
Linux kernel ============ The Linux kernel is the core of any Linux operating system. It manages hardware, system resources, and provides the fundamental services for all other software. Quick Start ----------- * Report a bug: See Documentation/admin-guide/reporting-issues.rst * Get the latest kernel: https://kernel.org * Build the kernel: See Documentation/admin-guide/quickly-build-trimmed-linux.rst * Join the community: https://lore.kernel.org/ Essential Documentation ----------------------- All users should be familiar with: * Building requirements: Documentation/process/changes.rst * Code of Conduct: Documentation/process/code-of-conduct.rst * License: See COPYING Documentation can be built with make htmldocs or viewed online at: https://www.kernel.org/doc/html/latest/ Who Are You? ============ Find your role below: * New Kernel Developer - Getting started with kernel development * Academic Researcher - Studying kernel internals and architecture * Security Expert - Hardening and vulnerability analysis * Backport/Maintenance Engineer - Maintaining stable kernels * System Administrator - Configuring and troubleshooting * Maintainer - Leading subsystems and reviewing patches * Hardware Vendor - Writing drivers for new hardware * Distribution Maintainer - Packaging kernels for distros * AI Coding Assistant - LLMs and AI-powered development tools For Specific Users ================== New Kernel Developer -------------------- Welcome! Start your kernel development journey here: * Getting Started: Documentation/process/development-process.rst * Your First Patch: Documentation/process/submitting-patches.rst * Coding Style: Documentation/process/coding-style.rst * Build System: Documentation/kbuild/index.rst * Development Tools: Documentation/dev-tools/index.rst * Kernel Hacking Guide: Documentation/kernel-hacking/hacking.rst * Core APIs: Documentation/core-api/index.rst Academic Researcher ------------------- Explore the kernel's architecture and internals: * Researcher Guidelines: Documentation/process/researcher-guidelines.rst * Memory Management: Documentation/mm/index.rst * Scheduler: Documentation/scheduler/index.rst * Networking Stack: Documentation/networking/index.rst * Filesystems: Documentation/filesystems/index.rst * RCU (Read-Copy Update): Documentation/RCU/index.rst * Locking Primitives: Documentation/locking/index.rst * Power Management: Documentation/power/index.rst Security Expert --------------- Security documentation and hardening guides: * Security Documentation: Documentation/security/index.rst * LSM Development: Documentation/security/lsm-development.rst * Self Protection: Documentation/security/self-protection.rst * Reporting Vulnerabilities: Documentation/process/security-bugs.rst * CVE Procedures: Documentation/process/cve.rst * Embargoed Hardware Issues: Documentation/process/embargoed-hardware-issues.rst * Security Features: Documentation/userspace-api/seccomp_filter.rst Backport/Maintenance Engineer ----------------------------- Maintain and stabilize kernel versions: * Stable Kernel Rules: Documentation/process/stable-kernel-rules.rst * Backporting Guide: Documentation/process/backporting.rst * Applying Patches: Documentation/process/applying-patches.rst * Subsystem Profile: Documentation/maintainer/maintainer-entry-profile.rst * Git for Maintainers: Documentation/maintainer/configure-git.rst System Administrator -------------------- Configure, tune, and troubleshoot Linux systems: * Admin Guide: Documentation/admin-guide/index.rst * Kernel Parameters: Documentation/admin-guide/kernel-parameters.rst * Sysctl Tuning: Documentation/admin-guide/sysctl/index.rst * Tracing/Debugging: Documentation/trace/index.rst * Performance Security: Documentation/admin-guide/perf-security.rst * Hardware Monitoring: Documentation/hwmon/index.rst Maintainer ---------- Lead kernel subsystems and manage contributions: * Maintainer Handbook: Documentation/maintainer/index.rst * Pull Requests: Documentation/maintainer/pull-requests.rst * Managing Patches: Documentation/maintainer/modifying-patches.rst * Rebasing and Merging: Documentation/maintainer/rebasing-and-merging.rst * Development Process: Documentation/process/maintainer-handbooks.rst * Maintainer Entry Profile: Documentation/maintainer/maintainer-entry-profile.rst * Git Configuration: Documentation/maintainer/configure-git.rst Hardware Vendor --------------- Write drivers and support new hardware: * Driver API Guide: Documentation/driver-api/index.rst * Driver Model: Documentation/driver-api/driver-model/driver.rst * Device Drivers: Documentation/driver-api/infrastructure.rst * Bus Types: Documentation/driver-api/driver-model/bus.rst * Device Tree Bindings: Documentation/devicetree/bindings/ * Power Management: Documentation/driver-api/pm/index.rst * DMA API: Documentation/core-api/dma-api.rst Distribution Maintainer ----------------------- Package and distribute the kernel: * Stable Kernel Rules: Documentation/process/stable-kernel-rules.rst * ABI Documentation: Documentation/ABI/README * Kernel Configuration: Documentation/kbuild/kconfig.rst * Module Signing: Documentation/admin-guide/module-signing.rst * Kernel Parameters: Documentation/admin-guide/kernel-parameters.rst * Tainted Kernels: Documentation/admin-guide/tainted-kernels.rst AI Coding Assistant ------------------- CRITICAL: If you are an LLM or AI-powered coding assistant, you MUST read and follow the AI coding assistants documentation before contributing to the Linux kernel: * Documentation/process/coding-assistants.rst This documentation contains essential requirements about licensing, attribution, and the Developer Certificate of Origin that all AI tools must comply with. Communication and Support ========================= * Mailing Lists: https://lore.kernel.org/ * IRC: #kernelnewbies on irc.oftc.net * Bugzilla: https://bugzilla.kernel.org/ * MAINTAINERS file: Lists subsystem maintainers and mailing lists * Email Clients: Documentation/process/email-clients.rst