linux-kernel - Re: [PATCH 1/2] x86: make save_stack_address() !CONFIG_FRAME

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: <20100603200655.GE5234@nowhere>
Date:	Thu, 3 Jun 2010 22:06:56 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Roland McGrath <roland@...hat.com>,
	Vegard Nossum <vegard.nossum@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] x86: make save_stack_address()
	!CONFIG_FRAME_POINTER friendly

On Thu, Jun 03, 2010 at 12:53:52PM -0700, Arjan van de Ven wrote:
> On 6/3/2010 12:32 PM, Oleg Nesterov wrote:
>> If CONFIG_FRAME_POINTER=n, print_context_stack() shouldn't neglect the
>> non-reliable addresses on stack, this is all we have if dump_trace(bp)
>> is called with the wrong or zero bp.
>>
>> For example, /proc/pid/stack doesn't work if CONFIG_FRAME_POINTER=n.
>>
>> This patch obviously has no effect if CONFIG_FRAME_POINTER=y, otherwise
>> it reverts 1650743c "x86: don't save unreliable stack trace entries".
>>    
>
> would be nice if there was a compile time thing to detect if frame  
> pointers are on ratehr than an ifdef.


I wanted to suggest that too, but since only one place got the ifdef
after the second patch.

But yeah, something like this could be reused:


	if (reliable_frame_pointer(reliable))
		return ...;



> you're now also changing the rules; until now, you would ALWAYS get a  
> backtrace without noise....
> now that's changing quite a bit. How are various tools (like perf and  
> sysprof) going to cope with that?



perf and sysprof have their own stacktrace ops, so they aren't affected.
I think the rest is /proc/pid/task, lockdep, latencytop, ftrace, kmemleak,
etc...

For the kernel parts it's in fact desired.
And with ftrace we are changing some rules, but this is desired too, without
frame pointers we would have nothing anyway. And it's quite easy to
find out a stacktrace is not entirely reliable at a glance.

--
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/