On Fri, 19 Jun 2020 13:29:09 +0800, 孙世龙 said:

I have never seen such a call trace log before: there is a question mark(i.e. symbol of "?") in front of the function name. What does the question mark imply?

Here is the related log:

[22041.387697] Call Trace [22041.387711] dump_stack+0x9e/0xc8 [22041.387718] warn_alloc+0x100/0x190 [22041.387725] __alloc_pages_slowpath+0xb93/0xbd0 [22041.387732] __alloc_pages_nodemask+0x26d/0x2b0 [22041.387739] alloc_pages_current+0x6a/0xe0 [22041.387744] kmalloc_order+0x18/0x40 [22041.387748] kmalloc_order_trace+0x24/0xb0 [22041.387754] __kmalloc+0x20e/0x230 [22041.387759] ? __vmalloc_node_range+0x171/0x250 [22041.387765] xnheap_init+0x87/0x200 [22041.387770] ? remove_process+0xc0/0xc0 [22041.387775] cobalt_umm_init+0x61/0xb0

There's various ways the stack unwinder for the call trace can work. On some architectures, there is an explicit stack pointer register, and it's saved in the stack by the 'call' opcode, so unwinding can be exact. On other systems, an explicit stack pointer is optional (such as on x86, where not building with one allows one more temporary register, which can help with efficient code generation). There, unwinds are inexact - it basically steps through the stack and finds entries that are viable pointers into the kernel/module executable code space. Sometimes, it will find what looks like a return pointer but it's not at a plausible location in the stack entry, so it may be trash left on the stack, so it flags it with a '?'