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 '?'