kernel BUG
https://kernelnewbies.org/FAQ/BUG
BUG() and BUG_ON(condition) are used as a debugging help when something in the kernel goes terribly wrong. When a BUG_ON() assertion fails, or the code takes a branch with BUG() in it, the kernel will print out the contents of the registers and a stack trace. After that the current process will die.
The following are examples of how BUG() and BUG_ON() are used, from a piece of code that is not supposed to run in interrupt context. The explicit if with BUG() is the coding style used in older kernels. In the 2.6 kernel, generally BUG_ON() is preferred.
if (in_interrupt()) BUG(); BUG_ON(in_interrupt());
How it works
1 2 3 4 5 | #define BUG() \ do { \ asm volatile ( "ud2" ); \ unreachable(); \ } while (0) |
unreachable():
https://lkml.org/lkml/2016/2/10/821
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | Hi, I noticed that the use of the function -- unreachable() -- inside of the BUG() macro in arch/x86/include/asm/bug.h causes compiler output to be suspect based on review of assembly output for quite a few areas. if as a test, you remove the call to unreachable() in the BUG() macro, it seems to generate a large number of build warnings about the use of uninitialized variables that are apparently masked by the compiler since it believes this code is going to halt, even in the cases where the BUG() macro is used conditionally, as in an if (condition) then BUG() (which the compiler does not seem to understand). This seems to indicate that the use of these built in macros telling the compiler to create a bunch of infinite jump labels is masking quite a few bugs lurking around in the regular code since gcc apparently just throws out the checks for uninitialized variables in any function if it sees this macro anywhere in the function. |
BUG() is defined as an invalid instruction, which means the CPU will throw an invalid opcode exception. This is caught in arch/i386/kernel/entry.S, in the invalid_op entry point, which calls the generated function do_invalid_op from arch/i386/kernel/traps.c. The following macros generate the do_invalid_op() function:
#define DO_ERROR_INFO(trapnr, signr, str, name, sicode, siaddr) \ fastcall void do_##name(struct pt_regs * regs, long error_code) \ { \ siginfo_t info; \ info.si_signo = signr; \ info.si_errno = 0; \ info.si_code = sicode; \ info.si_addr = (void __user *)siaddr; \ if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) \ == NOTIFY_STOP) \ return; \ do_trap(trapnr, signr, str, 0, regs, error_code, &info); \ } DO_ERROR_INFO( 6, SIGILL, "invalid opcode", invalid_op, ILL_ILLOPN, regs->eip)
The do_trap() function will discover that the trap happened while running in kernel mode, and that there is no fixup for exceptions that happen while running at this address. See FAQ/TestWpBit to learn about exception fixups.
kernel_trap: { if (!fixup_exception(regs)) die(str, regs, error_code); return; }
That in turn means that the current thread dies, printing a register dump and stack trace before it goes. The die() function has some magic of its own, which I won't go into here.
[yaowei@BCLinux linux]$ less arch/x86/kernel/crash
crash.c crash_dump_32.c crash_dump_64.c
[yaowei@BCLinux linux]$ less arch/x86/kernel/dumpstack
dumpstack_32.c dumpstack_64.c dumpstack.c
[yaowei@BCLinux linux]$ less arch/x86/kernel/traps.c
[yaowei@BCLinux linux]$ less kernel/panic.c
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】博客园携手 AI 驱动开发工具商 Chat2DB 推出联合终身会员
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步