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%
b6f74dff6d
netdev_lockdep_set_classes() puts dev->lock in a separate lockdep class, by type (netkit vs dummy etc), with the intent of keeping the instance locks of individual devices as independent from each other as possible. In practice it does the opposite. lockdep only calls the cmp_fn for locks of the same class, so netdev_lock_cmp_fn() never gets a say when devices from different classes are nested. Instead lockdep records a dependency between the classes, and reports a circular locking problem as soon as the nesting happens the other way round, e.g. when devices are unregistered in a batch. ====================================================== WARNING: possible circular locking dependency detected 7.3.0-rc3+ #26 Not tainted ------------------------------------------------------ kworker/u256:1/326 is trying to acquire lock: ff110000104fce28 (&dev_instance_lock_key#6){+.+.}-{4:4}, at: unregister_netdevice_many_notify+0x1141/0x1c30 but task is already holding lock: ff110000127f2e28 (&dev_instance_lock_key#7){+.+.}-{4:4}, at: unregister_netdevice_many_notify+0x1141/0x1c30 -> #1 (&dev_instance_lock_key#7){+.+.}-{4:4}: __lock_acquire+0x767/0xd60 lock_acquire.part.0+0xd0/0x260 __mutex_lock+0x17d/0x1f20 unregister_netdevice_many_notify+0x1141/0x1c30 default_device_exit_batch+0x3ee/0x520 ops_undo_list+0x2cc/0x8a0 cleanup_net+0x442/0x9c0 process_one_work+0x951/0x1ab0 worker_thread+0x5a6/0xd10 kthread+0x339/0x430 ret_from_fork+0x4a4/0x6f0 ret_from_fork_asm+0x1a/0x30 -> #0 (&dev_instance_lock_key#6){+.+.}-{4:4}: check_prev_add+0xeb/0xe60 validate_chain+0x598/0x900 __lock_acquire+0x767/0xd60 lock_acquire.part.0+0xd0/0x260 __mutex_lock+0x17d/0x1f20 unregister_netdevice_many_notify+0x1141/0x1c30 default_device_exit_batch+0x3ee/0x520 ops_undo_list+0x2cc/0x8a0 cleanup_net+0x442/0x9c0 process_one_work+0x951/0x1ab0 worker_thread+0x5a6/0xd10 kthread+0x339/0x430 ret_from_fork+0x4a4/0x6f0 ret_from_fork_asm+0x1a/0x30 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev_instance_lock_key#7); lock(&dev_instance_lock_key#6); lock(&dev_instance_lock_key#7); lock(&dev_instance_lock_key#6); *** DEADLOCK *** locks held by kworker/u256:1/326: 6, last CPU#6: #0: ff11000001c2b540 ((wq_completion)netns){+.+.}-{0:0}, at: process_one_work+0x117c/0x1ab0 #1: ffa0000001a3fd18 (net_cleanup_work){+.+.}-{0:0}, at: process_one_work+0x8ce/0x1ab0 #2: ffffffff98f53288 (pernet_ops_rwsem){++++}-{4:4}, at: cleanup_net+0xc1/0x9c0 #3: ffffffff98f6ede0 (rtnl_mutex){+.+.}-{4:4}, at: default_device_exit_batch+0x92/0x520 #4: ff1100001321ae28 (&dev_instance_lock_key#7){+.+.}-{4:4}, at: unregister_netdevice_many_notify+0x1141/0x1c30 We can't put all devices in the same class, that'd be too permissive. netdev_nl_queue_create_doit() and netdev_nl_bind_tx_doit() lock a virtual device (netkit) before a physical device, without rtnl_lock. We can never allow locking in the opposite order even under rtnl_lock. cmp_fn cannot enforce this sort of rule: lockdep keys its chain cache on the sequence of lock classes, so with a single class both orders hash to the same chain and only whichever happens first is validated. netdev_lock_cmp_fn() itself has another source of false-negatives. lockdep calls it from within __lock_acquire(), with the recursion counter already raised, so lock_is_held_type() always returns LOCK_STATE_UNKNOWN, which means lockdep_rtnl_is_held() always returns true / held. Use rtnl_is_locked(), which looks at the mutex directly and does work from that context. We may still miss a bad case if some other process is holding the lock, not us, but that's better than the 100% false negative rate of lockdep_rtnl_is_held(). One last thing, lockdep compares the address of the cmp function, so it can't be a static inline - that would work similarly to having separate classes, again. Move it to a source file. Tested by nesting two instance locks from a module, one scenario per boot since the first splat turns debug_locks off: first second rtnl reported ----------------------------------------------------------- virt->virt no recursive locking virt->virt yes - virt->phys no - virt->phys yes - phys->virt no - (records the edge) phys->virt yes - (records the edge) phys->phys no recursive locking phys->phys yes - virt->phys phys->virt no, no circular dependency virt->phys phys->virt no, yes circular dependency virt->phys phys->virt yes, no circular dependency virt->phys phys->virt yes, yes circular dependency phys->virt virt->phys no, no circular dependency phys->virt virt->phys yes, yes circular dependency virt->virt virt->virt yes, no recursive locking phys->phys phys->phys yes, no recursive locking (netkit and dummy stood in for the virtual devices, virtio_net and netdevsim for the physical ones.) Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20260926041832.1649675-1-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> |
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