linux-kernel - Re: [tip:x86/asm] x86/dumpstack: Pin the target stack when dumping it

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, 16 Sep 2016 14:57:54 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     tip-bot for Andy Lutomirski <tipbot@...or.com>,
        linux-tip-commits@...r.kernel.org, luto@...nel.org, hpa@...or.com,
        dvlasenk@...hat.com, linux-kernel@...r.kernel.org, jann@...jh.net,
        peterz@...radead.org, torvalds@...ux-foundation.org,
        brgerst@...il.com, tglx@...utronix.de, bp@...en8.de
Subject: Re: [tip:x86/asm] x86/dumpstack: Pin the target stack when dumping it


* Josh Poimboeuf <jpoimboe@...hat.com> wrote:

> On Fri, Sep 16, 2016 at 06:55:57AM -0500, Josh Poimboeuf wrote:
> > On Fri, Sep 16, 2016 at 02:17:46AM -0700, tip-bot for Andy Lutomirski wrote:
> > > Commit-ID:  1959a60182f48879635812a03a99c02231ea8677
> > > Gitweb:     http://git.kernel.org/tip/1959a60182f48879635812a03a99c02231ea8677
> > > Author:     Andy Lutomirski <luto@...nel.org>
> > > AuthorDate: Thu, 15 Sep 2016 22:45:45 -0700
> > > Committer:  Ingo Molnar <mingo@...nel.org>
> > > CommitDate: Fri, 16 Sep 2016 09:18:53 +0200
> > > 
> > > x86/dumpstack: Pin the target stack when dumping it
> > > 
> > > Specifically, pin the stack in save_stack_trace_tsk() and
> > > show_trace_log_lvl().
> > > 
> > > This will prevent a crash if the target task dies before or while
> > > dumping its stack once we start freeing task stacks early.
> > 
> > This causes a hang:
> 
> The problem is that show_stack_log_lvl() can be called with a NULL
> task_struct pointer to indicate 'current'.

Could you please send a quick fix that addresses the hang by turning the NULL into 
'current' or so?

> No idea why that convention exists -- IMO we should just require the
> caller to pass 'current' directly.

For hysterical raisins I believe. It appears just a single caller passes 
non-current. Feel free to change this.

Thanks,

	Ingo