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] [day] [month] [year] [list]
Message-ID: <20150826221224.GT19120@codeaurora.org>
Date:	Wed, 26 Aug 2015 15:12:24 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Douglas Anderson <dianders@...omium.org>
Cc:	Russell King <linux@....linux.org.uk>,
	Nicolas Pitre <nico@...aro.org>,
	Aapo Vienamo <avienamo@...dia.com>,
	Jason Wessel <jason.wessel@...driver.com>, tixy@...aro.org,
	masami.hiramatsu.pt@...achi.com, wangnan0@...wei.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] arm: kgdb: Fix registers on sleeping tasks

On 08/26, Douglas Anderson wrote:
> From: Doug Anderson <dianders@...omium.org>
> 
> Dumping registers from other sleeping tasks in KGDB was totally
> failing for me.  All registers were reported as 0 in many cases.
> 
> The code was using task_pt_regs(task) to try to get other thread
> registers.  This doesn't appear to be the right place to look.  From
> my tests, I saw non-zero values in this structure when we were looking
> at a kernel thread that had a userspace task associated with it, but
> it contained the register values from the userspace task.  So even in
> the cases where registers weren't reported as 0 we were still not
> showing the right thing.
> 
> Instead of using task_pt_regs(task) let's use task_thread_info(task).
> This is the same place that is referred to when doing a dump of all
> sleeping task stacks (kdb_show_stack() -> show_stack() ->
> dump_backtrace() -> unwind_backtrace() -> thread_saved_sp()).
> 
> As further evidence that this is the right thing to do, you can find
> the following comment in "gdbstub.c" right before it calls
> sleeping_thread_to_gdb_regs():
>   Pull stuff saved during switch_to; nothing else is accessible (or
>   even particularly relevant).  This should be enough for a stack
>   trace.
> ...and if you look at switch_to() it only saves r4-r11, sp and lr.
> Those are the same registers that I'm getting out of the
> task_thread_info().
> 
> With this change you can use "info thread" to see all tasks in the
> kernel and you can switch to other tasks and examine them in gdb.
> 
> Signed-off-by: Doug Anderson <dianders@...omium.org>
> Signed-off-by: Douglas Anderson <dianders@...omium.org>
> ---

Works for me.

Tested-by: Stephen Boyd <sboyd@...eurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ