kernel

Verified·Scanned 2/18/2026

Avoid common Linux kernel mistakes — atomic context violations, allocation failures, and locking traps.

from clawhub.ai·v8d6b348·2.1 KB·0 installs
Scanned from 1.0.0 at 8d6b348 · Transparency log ↗
$ vett add clawhub.ai/ivangdavila/kernel

Atomic Context Traps

  • spin_lock held = cannot sleep — no kmalloc(GFP_KERNEL), no mutex_lock, no copy_from_user
  • Interrupt can take same spinlock — must use spin_lock_irqsave, not plain spin_lock
  • rcu_read_lock() section cannot sleep — no blocking calls inside RCU read-side
  • might_sleep() annotation — add to functions that may sleep, catches bugs with CONFIG_DEBUG_ATOMIC_SLEEP

Allocation Failures

  • GFP_ATOMIC can return NULL — always check, don't assume success
  • vmalloc memory not physically contiguous — cannot use for DMA
  • kzalloc over kmalloc — uninitialized memory leaks kernel info to userspace
  • Allocation in loop risks OOM — preallocate or use memory pool

User Pointer Handling

  • copy_from_user returns bytes NOT copied — 0 means success, not failure
  • Never use %s with user pointer in printk — kernel crash or info leak
  • User memory can change during syscall — copy to kernel buffer, validate the copy
  • __user annotation is documentation — doesn't enforce anything, you must use copy functions

Memory Ordering

  • READ_ONCE/WRITE_ONCE for lockless shared data — prevents compiler from caching/reordering
  • Spinlock release has implicit barrier — but check-then-act patterns still need care
  • smp_wmb() before publishing pointer — ensures data visible before pointer is

Module Error Paths

  • Init fails midway — must undo everything already done
  • Reverse order cleanup — unregister in opposite order of register
  • goto err_* pattern standard — cleaner than nested ifs
  • Check what's actually initialized — don't free/unregister what wasn't set up

Locking Mistakes

  • Same lock acquired twice = deadlock — even in different functions
  • Inconsistent lock ordering — document order, acquire in same sequence everywhere
  • mutex_trylock returns 1 on success — opposite of pthread_mutex_trylock
  • Reader-writer locks rarely worth it — contention overhead usually exceeds benefit