Re: ORC unwinder and 'reliable' flag to printk_stack_address()

[Jiri Kosina]

On Wed, 6 Sep 2017, Josh Poimboeuf wrote:

> > 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.

It's interesting though that all of them (and even in other instances I've 
encountered in the meantime) are always at the "last address" of the 
function address range. That's hardly a conincidence, and also hardly a 
result of a legitimate stacktrace -- 'call' is rather unlikely to be the 
last insn in a function.

> 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.

Ah, I've missed that when looking at the code, now I see it. Thanks,

-- 
Jiri Kosina
SUSE Labs