All of lore.kernel.org
 help / color / mirror / Atom feed
From: "tiejun.chen" <tiejun.chen@windriver.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] kmemleak/module: only scan the existed data section
Date: Tue, 10 Jan 2012 10:59:42 +0800	[thread overview]
Message-ID: <4F0BA99E.1090006@windriver.com> (raw)
In-Reply-To: <CAHkRjk5fuubEQaq2CD1cGE=W+Lf6svE6fN8KyDrY6=i3-=b_RA@mail.gmail.com>

Catalin Marinas wrote:
> On 28 December 2011 08:11, Tiejun Chen <tiejun.chen@windriver.com> wrote:
>> We should only scan the sections containing data and it's size is not
>> zero as well.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
>> ---
>> �kernel/module.c | � �2 ++
>> �1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/kernel/module.c b/kernel/module.c
>> index 12cfa2b..0b93c30 100644
>> --- a/kernel/module.c
>> +++ b/kernel/module.c
>> @@ -2045,6 +2045,8 @@ static void kmemleak_load_module(struct module *mod, Elf_Ehdr *hdr,
>> � � � � � � � �if (strncmp(secstrings + sechdrs[i].sh_name, ".data", 5) != 0
>> � � � � � � � � � �&& strncmp(secstrings + sechdrs[i].sh_name, ".bss", 4) != 0)
>> � � � � � � � � � � � �continue;
>> + � � � � � � � if (sechdrs[i].sh_size == 0)
>> + � � � � � � � � � � � continue;
>>
>> � � � � � � � �kmemleak_scan_area((void *)sechdrs[i].sh_addr,
>> � � � � � � � � � � � � � � � � � sechdrs[i].sh_size, GFP_KERNEL);
> 
> I would rather move this check to kmemleak.c. But why would it be
> needed? Performance? A zero-size area shouldn't be scanned anyway.

When we call layout_sections() to calculate sh_entsize, often a zero-sized
.data/.bss section would be ordered as a middle of all valid sections. For example,
------
Symbol			Addr		size

.init.			0xf96d3000
......
.data(or .bss) 		0xf96d3180	0
......			0xf96d4000		

If so kmemleak_scan_area(0xf96d3180,0,GFP_KERNEL) is fine as we expect since
0xf96d3180 is always within a valid address scopes summarized all section,
0xf96d3000 ~  0xf96d4000. But sometimes if that is arranged as a last section:
-----
Symbol			Addr		size

.init.			0xf96d3000
......
.data(or .bss) 		0xf96d3180	0


An then the following call trace is triggered
......
kmemleak: Adding scan area to unknown object at 0xf96d3180
Call Trace:
[e9095de0] [c0008588] show_stack+0x68/0x1d8 (unreliable)
[e9095e30] [c0690094] dump_stack+0x2c/0x44
[e9095e40] [c015a190] kmemleak_scan_area+0x128/0x184
[e9095e70] [c00a145c] load_module+0xa98/0x1c04
[e9095f10] [c00a2650] sys_init_module+0x88/0x24c
[e9095f40] [c0012f7c] ret_from_syscall+0x0/0x4
--- Exception: c01 at 0xff63564
    LR = 0x10003414

Tiejun

  reply	other threads:[~2012-01-10  2:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-28  8:11 [PATCH 1/1] kmemleak/module: only scan the existed data section Tiejun Chen
2012-01-09  0:59 ` tiejun.chen
2012-01-09 12:05 ` Catalin Marinas
2012-01-10  2:59   ` tiejun.chen [this message]
2012-01-10 10:59     ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F0BA99E.1090006@windriver.com \
    --to=tiejun.chen@windriver.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.