Analyzing processor registers during a kernel crash

You should understand that you are testing (not debugging) at the assembly level (not in source code). It is important that you keep yourself in mind when inspecting emergency dumps.

You should carefully read the drop date report line by line because it contains a lot of information as well as everything you got.

When you got the place where your code was broken, you should figure out why this happened by reading the report and dumping the crash dump.

The first line of the dump failure report states

BUG: unable to handle kernel paging request at ffffc90028213000

      

        
        
        
      

    

This means that you are using invalid memory.

Line

Process diseproc (pid: 1126, threadinfo ffff880435fc4000, task ffff8807f8be8ae0)

      

        
        
        
      

    

reports what happened in user space during the crash. It looks like the userpace process diseproc

issued some command to your driver causing it to crash.

Very important line

IP: [<ffffffffa0180279>] debug_fucntion+0x19/0x160 [dise]

      

        
        
        
      

    

Try issuing a command dis debug_function

to parse debug_function, find debug_function+25

(0x19 hex = 25 dec) and look around. Read it alongside the C source code for debug_function. You can usually find the location of the failure in C code by comparing the instructions callq

- disassembling will display the name of the called call for printing. In the meantime, there is no need to worry about it. ”

Next and most important is the call trace:

Call Trace:
 [<ffffffffa0180498>] cmd_dump+0x1c8/0x360 [dise]
 [<ffffffffa01978e1>] debug_log_show+0x91/0x160 [dise]
 [<ffffffffa013afb9>] process_debug+0x5a9/0x990 [dise]
 [<ffffffff810792c7>] ? current_fs_time+0x27/0x30
 [<ffffffffa013bc38>] dise_ioctl+0xd8/0x300 [dise]
 [<ffffffff8105a501>] ? hotplug_hrtick+0x21/0x60
 [<ffffffff8119db42>] vfs_ioctl+0x22/0xa0
 [<ffffffff8119dce4>] do_vfs_ioctl+0x84/0x580
 [<ffffffff8119e261>] sys_ioctl+0x81/0xa0
 [<ffffffff810e1e5e>] ? __audit_syscall_exit+0x25e/0x290
 [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b

      

        
        
        
      

    

Reading top to bottom: the kernel got ioctl (from diseproc, apparently), ioctl handler handler kernel dise_ioctl

module disease, then current_fs_time

, process_debug

, debug_log_show

and, finally cmd_dump

.

Now you know:

• Code: dise_ioctl
  
  → current_fs_time
  
  → process_debug
  
  → debug_log_show
  
  → cmd_dump
  
  → somehow before debug_function
  
  .
• Approximate place in C code that caused the crash
• Cause of failure: Invalid memory access

With this information, you must use your last and most powerful method - thinking. Try to understand which variables / structures caused the crash. Maybe some of them were released by the time you arrived at debug_function

? Maybe you are wrong about pointer arithmetic?

Answers on questions:

• In most cases, the CPU register values ​​are meaningless because it has nothing to do with your C code. Just some values ​​pointing to some kind of memory - whatever. Yes, there are some extremely useful registers like RIP / EIP and RSP / ESP, but most of them are way out of context.

• Very unlikely. You are not actually debugging - you are checking your dump - you have no debugging context.

• I agree with @ user2699113 that this is just the memory contents under the pointer from RIP.

And remember, the best debugging tool is your brain.