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

[Josh Poimboeuf]

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