0

I have written a kernel module and tested it in qemu. In general, it's ok to run. However, after long-term execution, the kernel might abort. The printed call trace is very wired where the addresses of called functioned aren't sequential.<ffffffffc0725fa5>, <ffffffffc0497e69>, <ffffffffc048953f>, <ffffffff9fc35cfc>, <ffffffffc0729f3e>, <ffffffffa01c539a>In my opinion, the addresses should be ascending.

On the other hand, I can't understand the whole call trace. There is even an uncalled function in the call trace. The entry is tamperhack_write which then calls kmem_cache_alloc_trace(but why? It doesn't call this function). The abort appears in kmem_cache_alloc_trace. With so, why tamperhack_write can still go on and call the user-defined tamper_is_safe_filename?

enter image description here

Update:

The biggest confusion is why the kernel aborts on kmem_cache_alloc_trace which I have never explicitly called in user-defined functions tamperhack_write and tamper_is_safe_filename. However, there are kmalloc and kfree in my code.

Virux
  • 138
  • 9
  • 2
    Stack is sequential. The address of functions are push on stack at consecutive locations but the function address themselves do not have to follow any order. – tstanisl Jun 26 '23 at 10:46
  • Does this answer your question? [What is the meaning of question marks '?' in Linux kernel panic call traces?](https://stackoverflow.com/questions/13113384/what-is-the-meaning-of-question-marks-in-linux-kernel-panic-call-traces) – Tsyvarev Jun 26 '23 at 12:12
  • "On the other hand, I can't understand the whole call trace. There is even an uncalled function in the call trace. " - In a call trace records, marked with `?`, are **unreliable**. If omitting these records gives reasonable trace, then this trace is most likely the actual one. – Tsyvarev Jun 26 '23 at 12:15
  • @tstanisl Thanks for your response. You mean these addresses represent function addresses instead of stack frame entry addresses? It is totally contradictory to my knowledge. In my mind, the aforementioned addresses should be stack frame entry addresses. Am I wrong? – Virux Jun 26 '23 at 14:39
  • @Tsyvarev Yes. Omitting those records with `?`, the whole trace seems more reasonable. However, the address of `system_call_fastpath`, which calls `tamper_write`, is still lower than `tamper_write`. This seems wired. – Virux Jun 26 '23 at 14:44
  • 1
    Addresses in the call trace represent addresses of the **"call" instructions**. These instructions are contained in the function's bodies, so the right side of the trace line represents the name of the function, where corresponding "call" instruction resides, and offset of that instruction in the function. Call trace doesn't contain addresses of the stack frames. – Tsyvarev Jun 26 '23 at 14:50

0 Answers0