lkml.org 
[lkml]   [2017]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ORC unwinder and 'reliable' flag to printk_stack_address()
On Tue, Sep 05, 2017 at 03:15:12PM +0200, Jiri Kosina wrote:
> Hi Josh,
>
> I just got the below stack trace with current Linus' tree with ORC
> unwinder enabled:
>
> [ 8.652765] Call Trace:
> [ 8.652767] dump_stack+0x7c/0xbf
> [ 8.652769] print_circular_bug+0x2d3/0x2e0
> [ 8.652771] check_prev_add+0x666/0x700
> [ 8.652772] ? print_bfs_bug+0x40/0x40
> [ 8.652775] lock_commit_crosslock+0x3f1/0x570
> [ 8.652777] complete+0x24/0x60
> [ 8.652779] __kthread_parkme+0x42/0x90
> [ 8.652780] smpboot_thread_fn+0x92/0x210
> [ 8.652782] kthread+0x145/0x180
> [ 8.652783] ? sort_range+0x20/0x20
> [ 8.652785] ? kthread_create_on_node+0x40/0x40
> [ 8.652787] ret_from_fork+0x2a/0x40
>
> Please note the kthread_create_on_node(), sort_range() and print_bfs_bug()
> entries ... I believe they actually shouldn't be there at all. All of them
> are at the last byte belonging to the function. Am I missing something?

The question marks are still supposed to be there. They show any text
addresses found on the stack that weren't otherwise found by the
unwinder. 99.9% of the time, they're left over from a previous call
chain, and should be ignored.

They can be confusing, but IIRC, Linus wants to keep them because:

a) If the unwinder gets confused, they'll still be printed.

b) For some really sneaky bugs, it can give a few clues about what
happened *before* the current trace.

Personally I've never seen (b), but (a) is definitely a good reason.

Note that while the "unreliable" addresses are shown for splats, they're
*not* reported by the unwinder for all its other uses like livepatch,
perf, /proc/<pid>/stack, etc.

--
Josh

\
 
 \ /
  Last update: 2017-09-07 00:38    [W:0.041 / U:6.272 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site