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]
Date:	Wed, 26 Nov 2008 11:24:47 +0800
From:	walimis <walimisdev@...il.com>
To:	Paul Mundt <lethal@...ux-sh.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Liming Wang <liming.wang@...driver.com>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] ftrace: adding other non-leaving .text sections

On Wed, Nov 26, 2008 at 12:18:50PM +0900, Paul Mundt wrote:
>On Wed, Nov 26, 2008 at 11:14:38AM +0800, walimis wrote:
>> On Wed, Nov 26, 2008 at 12:04:46PM +0900, Paul Mundt wrote:
>> >On Tue, Nov 25, 2008 at 10:03:35PM -0500, Steven Rostedt wrote:
>> >> 
>> >> On Wed, 26 Nov 2008, Liming Wang wrote:
>> >> 
>> >> > Please review this patch, and I don't know whether new sections will conflict 
>> >> > with sched tracer or others. 
>> >> > This patch is against Steven tree's tip/devel latest commit.
>> >> > 
>> >> > Impact: improve recordmcount.pl
>> >> > 
>> >> > Besides .text section, there are three .text sections that won't
>> >> > be freed after kernel booting. They are: .sched.text, .spinlock.text
>> >> > and .kprobes.text, which contain functions we can trace. But the last
>> >> > section ".kprobes.text" is particular, which has been marked as "notrace",
>> >> > we ignore it. Thus we add other two sections.
>> >> 
>> >> Yep, only those sections that we know will not disappear are OK. I was
>> >> conservative with only using ".text" but I knew there were other sections 
>> >> that were OK, so I used the hash array to make it easy to add others.
>> >> 
>> >Does your .text cover .text.head by the way?
>> No, and not needed. Because .text.head is of booting code, to which
>> function tracer can't trace.
>> 
>In the case of CPU hotplug it can be entered at any time. I don't see why
>it can't be traced from the boot CPU at least.
OK, I see. Need more investigating on it.
Thanks.

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