By now, the recordmcount only records the function that in
following sections:
.text/.ref.text/.sched.text/.spinlock.text/.irqentry.text/
.kprobes.text/.text.unlikely
For the function that not in these sections, the call mcount
will be in place and not be replaced when kernel boot up. And
it will bring performance overhead, such as do_mem_abort (in
.exception.text section). This patch make the call mcount to
nop for this case in recordmcount.
Signed-off-by: Li Bin <redacted>
---
scripts/recordmcount.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
From: Steven Rostedt <rostedt@goodmis.org> Date: 2015-10-28 08:16:33
On Wed, 28 Oct 2015 16:04:05 +0800
Li Bin [off-list ref] wrote:
By now, the recordmcount only records the function that in
following sections:
.text/.ref.text/.sched.text/.spinlock.text/.irqentry.text/
.kprobes.text/.text.unlikely
For the function that not in these sections, the call mcount
will be in place and not be replaced when kernel boot up. And
it will bring performance overhead, such as do_mem_abort (in
.exception.text section). This patch make the call mcount to
nop for this case in recordmcount.
I can take this in my tree with an Ack from the ARM64 maintainers.
-- Steve
quoted hunk
Signed-off-by: Li Bin <redacted>
---
scripts/recordmcount.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
From: Will Deacon <hidden> Date: 2015-10-28 11:58:31
On Wed, Oct 28, 2015 at 04:16:19AM -0400, Steven Rostedt wrote:
On Wed, 28 Oct 2015 16:04:05 +0800
Li Bin [off-list ref] wrote:
quoted
By now, the recordmcount only records the function that in
following sections:
.text/.ref.text/.sched.text/.spinlock.text/.irqentry.text/
.kprobes.text/.text.unlikely
For the function that not in these sections, the call mcount
will be in place and not be replaced when kernel boot up. And
it will bring performance overhead, such as do_mem_abort (in
.exception.text section). This patch make the call mcount to
nop for this case in recordmcount.
I can take this in my tree with an Ack from the ARM64 maintainers.
Looks like it does what it says on the tin:
Acked-by: Will Deacon [off-list ref]
Will
On Wed, Oct 28, 2015 at 04:16:19AM -0400, Steven Rostedt wrote:
quoted
On Wed, 28 Oct 2015 16:04:05 +0800
Li Bin [off-list ref] wrote:
quoted
By now, the recordmcount only records the function that in
following sections:
.text/.ref.text/.sched.text/.spinlock.text/.irqentry.text/
.kprobes.text/.text.unlikely
For the function that not in these sections, the call mcount
will be in place and not be replaced when kernel boot up. And
it will bring performance overhead, such as do_mem_abort (in
.exception.text section). This patch make the call mcount to
nop for this case in recordmcount.
The patch itself is fine (it might be a good idea to describe
what 0x94000000 means though), but
I'm wondering whether we have any reason to exclude .exception.text
from tracing.
In my understandings, this attribute (.exception.text) is utilized
solely for pretty printing in dump_backtrace().
Thanks,
-Takahiro AKASHI
quoted
I can take this in my tree with an Ack from the ARM64 maintainers.
Looks like it does what it says on the tin:
Acked-by: Will Deacon [off-list ref]
Will
/bin/bash: line 1: 117734 Segmentation fault ./scripts/recordmcount "arch/arm64/kernel/traps.o"
--
quoted
quoted
/bin/bash: line 1: 113824 Segmentation fault ./scripts/recordmcount "arch/arm64/mm/fault.o"
I can reproduce this locally with an allmodconfig build. The offset
parameter to make_nop_arm64 is nuts:
Program received signal SIGSEGV, Segmentation fault.
make_nop_arm64 (map=0x7ffff7fef000, offset=2600547309829750784) at scripts/recordmcount.c:170
170 if (*ptr != 0x94000000)
Both shdr->sh_offset (0x17000000000000) and relp->r_offset (0x2400000000000000)
look dodgy in the caller.
Li, can you take a look please?
Will
/bin/bash: line 1: 117734 Segmentation fault ./scripts/recordmcount "arch/arm64/kernel/traps.o"
--
quoted
quoted
/bin/bash: line 1: 113824 Segmentation fault ./scripts/recordmcount "arch/arm64/mm/fault.o"
I can reproduce this locally with an allmodconfig build. The offset
parameter to make_nop_arm64 is nuts:
Program received signal SIGSEGV, Segmentation fault.
make_nop_arm64 (map=0x7ffff7fef000, offset=2600547309829750784) at scripts/recordmcount.c:170
170 if (*ptr != 0x94000000)
Both shdr->sh_offset (0x17000000000000) and relp->r_offset (0x2400000000000000)
look dodgy in the caller.
The allmodconfig configs the CONFIG_CPU_BIG_ENDIAN, and the test system is little eddian, so
it triggers the error.
It is a bug in nop_mcount:
...
if (mcountsym == Elf_r_sym(relp) && !is_fake_mcount(relp)) {
if (make_nop) {
ret = make_nop((void *)ehdr, shdr->sh_offset + relp->r_offset);
}
...
shdr->sh_offset and welp->r_offset should handle endianness properly as _w(shdr->sh_offset)/
_w(relp->r_offset). I will post a patchset including this patch soon.
Thanks,
Li Bin
From: Steven Rostedt <rostedt@goodmis.org> Date: 2015-11-02 18:26:16
On Fri, 30 Oct 2015 14:00:28 +0800
libin [off-list ref] wrote:
It is a bug in nop_mcount:
...
if (mcountsym == Elf_r_sym(relp) && !is_fake_mcount(relp)) {
if (make_nop) {
ret = make_nop((void *)ehdr, shdr->sh_offset + relp->r_offset);
}
...
shdr->sh_offset and welp->r_offset should handle endianness properly as _w(shdr->sh_offset)/
_w(relp->r_offset). I will post a patchset including this patch soon.
From: Will Deacon <hidden> Date: 2015-11-02 18:28:42
On Mon, Nov 02, 2015 at 01:26:08PM -0500, Steven Rostedt wrote:
On Fri, 30 Oct 2015 14:00:28 +0800
libin [off-list ref] wrote:
quoted
It is a bug in nop_mcount:
...
if (mcountsym == Elf_r_sym(relp) && !is_fake_mcount(relp)) {
if (make_nop) {
ret = make_nop((void *)ehdr, shdr->sh_offset + relp->r_offset);
}
...
shdr->sh_offset and welp->r_offset should handle endianness properly as _w(shdr->sh_offset)/
_w(relp->r_offset). I will post a patchset including this patch soon.
From: Steven Rostedt <rostedt@goodmis.org> Date: 2015-11-02 19:34:43
On Mon, 2 Nov 2015 18:28:37 +0000
Will Deacon [off-list ref] wrote:
I see you're playing "chase the patches" at the moment ;)
Why yes I am!
Trying to grab last minute patches from my INBOX (or they could be old
patches that I just missed), before kicking off my 12 hour test suite.
-- Steve