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]
Message-ID: <nycvar.YFH.7.76.1709081309140.3285@jbgna.fhfr.qr>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ