There is a question mark in front of the function name in the call trace log.What does the question mark imply?

There is a question mark in front of the function name in the call trace log.What does the question mark imply?

[孙世龙]

[-- Attachment #1.1: Type: text/plain, Size: 1343 bytes --]

Hi,

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

[22041.387779] cobalt_process_attach+0x64/0x4c0

[22041.387784] ? snprintf+0x45/0x70

[22041.387790] ? security_capable+0x46/0x60

[22041.387794] bind_personality+0x5a/0x120

[22041.387798] cobalt_bind_core+0x27/0x60

[22041.387803] CoBaLt_bind+0x18a/0x1d0

[22041.387812] ? handle_head_syscall+0x3f0/0x3f0

[22041.387816] ipipe_syscall_hook+0x119/0x340

[22041.387822] __ipipe_notify_syscall+0xd3/0x190

[22041.387827] ? __x64_sys_rt_sigaction+0x7b/0xd0

[22041.387832] ipipe_handle_syscall+0x3e/0xc0

[22041.387837] do_syscall_64+0x3b/0x250

[22041.387842] entry_SYSCALL_64_after_hwframe+0x44/0xa9

[-- Attachment #1.2: Type: text/html, Size: 25894 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: There is a question mark in front of the function name in the call trace log.What does the question mark imply?

[Valdis Klētnieks]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset=us-ascii, Size: 1548 bytes --]

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies