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:	Wed, 26 Nov 2008 12:18:50 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	walimis <walimisdev@...il.com>
Cc:	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 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.
--
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