kernel/dma/debug.c
Source file repositories/reference/linux-study-clean/kernel/dma/debug.c
File Facts
- System
- Linux kernel
- Corpus path
kernel/dma/debug.c- Extension
.c- Size
- 45060 bytes
- Lines
- 1671
- Domain
- Core OS
- Bucket
- Scheduler, Processes, Timers, Sync, And Syscalls
- Inferred role
- Core OS: operation-table or driver-model contract
- Status
- pattern implementation candidate
Why This File Exists
Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Defines an operation table; this is where Linux turns generic core objects into subsystem-specific behavior.
- Touches user memory; correctness depends on fault-safe copying and privilege boundary handling.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/sched/task_stack.hlinux/scatterlist.hlinux/dma-map-ops.hlinux/sched/task.hlinux/stacktrace.hlinux/spinlock.hlinux/vmalloc.hlinux/debugfs.hlinux/uaccess.hlinux/export.hlinux/device.hlinux/types.hlinux/sched.hlinux/ctype.hlinux/list.hlinux/slab.hlinux/swiotlb.hasm/sections.hdebug.h
Detected Declarations
struct dma_debug_entrystruct hash_bucketenum map_err_typesfunction dma_debug_disabledfunction dump_entry_tracefunction driver_filterfunction strncmpfunction hash_fnfunction put_hash_bucketfunction exact_matchfunction containing_matchfunction list_for_each_entryfunction hash_bucket_addfunction hash_bucket_delfunction to_cacheline_numberfunction active_cacheline_read_overlapfunction active_cacheline_set_overlapfunction active_cacheline_inc_overlapfunction active_cacheline_dec_overlapfunction active_cacheline_insertfunction active_cacheline_removefunction debug_dma_dump_mappingsfunction list_for_each_entryfunction dump_showfunction list_for_each_entryfunction add_dma_entryfunction dma_get_cache_alignmentfunction dma_debug_create_entriesfunction __dma_entry_alloc_check_leakfunction dma_entry_freefunction filter_readfunction filter_writefunction characterfunction dma_debug_fs_initfunction device_dma_allocationsfunction list_for_each_entryfunction dma_debug_device_changefunction dma_debug_add_busfunction dma_debug_initfunction dma_debug_cmdlinefunction dma_debug_entries_cmdlinefunction check_unmapfunction dma_mapping_errorfunction check_for_stackfunction check_for_illegal_areafunction check_syncfunction check_sg_segmentfunction debug_dma_map_single
Annotated Snippet
static struct device_driver *current_driver __read_mostly;
static DEFINE_RWLOCK(driver_name_lock);
static const char *const maperr2str[] = {
[MAP_ERR_CHECK_NOT_APPLICABLE] = "dma map error check not applicable",
[MAP_ERR_NOT_CHECKED] = "dma map error not checked",
[MAP_ERR_CHECKED] = "dma map error checked",
};
static const char *type2name[] = {
[dma_debug_single] = "single",
[dma_debug_sg] = "scatter-gather",
[dma_debug_coherent] = "coherent",
[dma_debug_noncoherent] = "noncoherent",
[dma_debug_phy] = "phy",
};
static const char *dir2name[] = {
[DMA_BIDIRECTIONAL] = "DMA_BIDIRECTIONAL",
[DMA_TO_DEVICE] = "DMA_TO_DEVICE",
[DMA_FROM_DEVICE] = "DMA_FROM_DEVICE",
[DMA_NONE] = "DMA_NONE",
};
/*
* The access to some variables in this macro is racy. We can't use atomic_t
* here because all these variables are exported to debugfs. Some of them even
* writeable. This is also the reason why a lock won't help much. But anyway,
* the races are no big deal. Here is why:
*
* error_count: the addition is racy, but the worst thing that can happen is
* that we don't count some errors
* show_num_errors: the subtraction is racy. Also no big deal because in
* worst case this will result in one warning more in the
* system log than the user configured. This variable is
* writeable via debugfs.
*/
static inline void dump_entry_trace(struct dma_debug_entry *entry)
{
#ifdef CONFIG_STACKTRACE
if (entry) {
pr_warn("Mapped at:\n");
stack_trace_print(entry->stack_entries, entry->stack_len, 0);
}
#endif
}
static bool driver_filter(struct device *dev)
{
struct device_driver *drv;
unsigned long flags;
bool ret;
/* driver filter off */
if (likely(!current_driver_name[0]))
return true;
/* driver filter on and initialized */
if (current_driver && dev && dev->driver == current_driver)
return true;
/* driver filter on, but we can't filter on a NULL device... */
if (!dev)
return false;
if (current_driver || !current_driver_name[0])
return false;
/* driver filter on but not yet initialized */
drv = dev->driver;
if (!drv)
return false;
/* lock to protect against change of current_driver_name */
read_lock_irqsave(&driver_name_lock, flags);
ret = false;
if (drv->name &&
strncmp(current_driver_name, drv->name, NAME_MAX_LEN - 1) == 0) {
current_driver = drv;
ret = true;
}
read_unlock_irqrestore(&driver_name_lock, flags);
return ret;
}
#define err_printk(dev, entry, format, arg...) do { \
Annotation
- Immediate include surface: `linux/sched/task_stack.h`, `linux/scatterlist.h`, `linux/dma-map-ops.h`, `linux/sched/task.h`, `linux/stacktrace.h`, `linux/spinlock.h`, `linux/vmalloc.h`, `linux/debugfs.h`.
- Detected declarations: `struct dma_debug_entry`, `struct hash_bucket`, `enum map_err_types`, `function dma_debug_disabled`, `function dump_entry_trace`, `function driver_filter`, `function strncmp`, `function hash_fn`, `function put_hash_bucket`, `function exact_match`.
- Atlas domain: Core OS / Scheduler, Processes, Timers, Sync, And Syscalls.
- Implementation status: pattern implementation candidate.
- This snippet crosses the user/kernel memory boundary; validate fault handling and access checks before translating the pattern.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.