linux-kernel - Re: ORC unwinder and 'reliable' flag to printk_stack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 8 Sep 2017 13:12:45 +0200 (CEST)
From:   Jiri Kosina <jikos@...nel.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
cc:     linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: ORC unwinder and 'reliable' flag to printk_stack_address()

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