include/linux/instrumentation.h
Source file repositories/reference/linux-study-clean/include/linux/instrumentation.h
File Facts
- System
- Linux kernel
- Corpus path
include/linux/instrumentation.h- Extension
.h- Size
- 1898 bytes
- Lines
- 61
- Domain
- Core OS
- Bucket
- Core Kernel Interface
- Inferred role
- Core OS: implementation source
- Status
- source 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.
Dependency Surface
linux/objtool.hlinux/stringify.h
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
* if (cond) {
* instrumentation_begin();
* ...
* instrumentation_end();
* }
* bar();
* instrumentation_end();
* }
*
* If instrumentation_end() would be an empty label, like all the other
* annotations, the inner _end(), which is at the end of a conditional block,
* would land on the instruction after the block.
*
* If we then consider the sum of the !cond path, we'll see that the call to
* bar() is with a 0-value, even though, we meant it to happen with a positive
* value.
*
* To avoid this, have _end() be a NOP instruction, this ensures it will be
* part of the condition block and does not escape.
*/
#define __instrumentation_end(c) ({ \
asm volatile(__stringify(c) ": nop\n\t" \
ANNOTATE_INSTR_END(__ASM_BREF(c)) \
: : "i" (c)); \
})
#define instrumentation_end() __instrumentation_end(__COUNTER__)
#else /* !CONFIG_NOINSTR_VALIDATION */
# define instrumentation_begin() do { } while(0)
# define instrumentation_end() do { } while(0)
#endif /* CONFIG_NOINSTR_VALIDATION */
#endif /* __LINUX_INSTRUMENTATION_H */
Annotation
- Immediate include surface: `linux/objtool.h`, `linux/stringify.h`.
- Atlas domain: Core OS / Core Kernel Interface.
- Implementation status: source implementation candidate.
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.