linux-kernel - Re: 答复: problem with kmemleak

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: <BANLkTinv6aSQMgh9ce1xaQ14_aHDPvFTxw@mail.gmail.com>
Date:	Mon, 16 May 2011 15:18:35 +0800
From:	ttlxzz ccc <boyzccc@...il.com>
To:	Catalin Marinas <catalin.marinas@....com>,
	Américo Wang <xiyou.wangcong@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: 答复: problem with kmemleak

Hi Catalin and Wang :)

I'm very glad to find the reason of this problem. It's just because
the CONFIG_FRAME_POINTER is not set :).

And in dump_stack() which is defined in arch/x86/kernel/dumpstack.c,
CONFIG_FRAME_POINTER control whether to get the bp.

Now I enable CONFIG_FRAME_POINTER and I can see the full backtrace. :)

Thank you very much for Catalin and Wang:).

On Fri, May 13, 2011 at 5:32 PM, ttlxzz ccc <boyzccc@...il.com> wrote:
> Hi, Wang and Catalin:
>
> I have tested kmemleak on the x86 and x86_64 architecture again. There is only
>  backtrace:
>
>   [<ffffffffffffffff>] 0xffffffffffffffff
>
> unreferenced object 0xffffc90012d27000 (size 64):
>
>  comm "insmod", pid 13092, jiffies 4298369684
>
>  hex dump (first 32 bytes):
>
>   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>
>   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>
>  backtrace:
>
>   [<ffffffffffffffff>] 0xffffffffffffffff
>
> But in the x86, there is full backtrace.
>  I do this below
>> cat .config | grep STACETRACE
>>
>> CONFIG_STACKTRACE_SUPPORT=y
>> CONFIG_STACKTRACE=y
>> CONFIG_USER_STACKTRACE_SUPPORT=y
>>
>> As you see, the x86_64 architecture supprot stacktrace. But I found
>> there's no backtrace yesterday.
>> I'll test it again later.
>>
>> BTW
>>
>> cat /proc/cpuinfo | grep processor | wc -l
>> 8
>> cat /proc/cpuinfo | grep model
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
>
> and My linux version is redhat 3.4.5
>
> Is it a problem of x86_64 architecture or something else? I am really
> very Anxious.
>
> Thanks:)
>
> On Fri, May 13, 2011 at 11:58 AM, ttlxzz ccc <boyzccc@...il.com> wrote:
>> Hi, wang
>> I have test kmemleak on the x86 architecture. There is no problem with
>> full backtrace.
>> But I can't test it on the x86_64 because my test machine is doing
>> something else.:(
>> But I do this below
>> cat .config | grep STACETRACE
>>
>> CONFIG_STACKTRACE_SUPPORT=y
>> CONFIG_STACKTRACE=y
>> CONFIG_USER_STACKTRACE_SUPPORT=y
>>
>> As you see, the x86_64 architecture supprot stacktrace. But I found
>> there's no backtrace yesterday.
>> I'll test it again later.
>>
>> BTW
>>
>> cat /proc/cpuinfo | grep processor | wc -l
>> 8
>> cat /proc/cpuinfo | grep model
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
>>
>> thank you :)
>>
>>
>> On Thu, May 12, 2011 at 10:49 PM, Américo Wang <xiyou.wangcong@...il.com> wrote:
>>> On Thu, May 12, 2011 at 10:33 PM, ttlxzz ccc <boyzccc@...il.com> wrote:
>>>> Thanks for Wangcong
>>>>
>>>> I have test the kmemleak-test.ko and the result includes no backtrace
>>>> except fffffffff, too.
>>>> I'm compling the kernel by make menuconfig. :)
>>>
>>> Odd, this looks like a bug, Cc Catalin Marinas <catalin.marinas@....com>
>>>
>>> I can't reach my test machine right now, I will try this tomorrow.
>>>
>>
>
--
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/