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

#define BUG()                                                   \
do {                                                            \
        asm volatile("ud2");                                    \
        unreachable();                                          \
} while (0)

unreachable():

https://lkml.org/lkml/2016/2/10/821

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