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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 25 Oct 2008 08:56:07 +0800
From:	"Peter Teoh" <htmldeveloper@...il.com>
To:	"Pekka Enberg" <penberg@...helsinki.fi>,
	"Eduard - Gabriel Munteanu" <eduard.munteanu@...ux360.ro>
Cc:	zanussi@...cast.net, jens.axboe@...cle.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PROBLEM] hard-lock with kmemtrace, relayfs, and splice

ok.   just ignore it.   i think based on "git log" of
"git://repo.or.cz/linux-2.6/kmemtrace.git":

commit 0441e5ff6ab71cf7a3e9ec3116f14d0fd7d20d51
Author: Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>
Date:   Thu Jul 10 20:20:05 2008 +0300

    kmemtrace: SLOB hooks.

the repo seemed way out of date.   But a clone of Pekka's slab-2.6's
topic/kmemtrace branch have no problem.   The steps are as follows:

1.   git clone git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6.git
2.   git checkout -m  origin/topic/kmemtrace
3.   git checkout -b kmemtrace

git log gives:

commit 51b19be3535c8fbcce6b6f838d89b9a6a4cc5b92
Author: Tom Zanussi <zanussi@...cast.net>
Date:   Fri Oct 10 23:58:51 2008 -0500

    relayfs: fix infinite loop with splice()

But the userspace tool I still get it from: git://repo.or.cz/kmemtrace-user.git

Correct?

Now I have some problems:

a.   I would like to extract out all the commit as diff - may I know
how to do that? ("git log" only gives the descriptive part).
b.   boot-time memory profiling....how can it be done (or extracted
out)?  (kmemtrace-user does not have that?)
c.   please provide some pointers to documentation:   how do I
interpret the following:

Allocation #83468 (CPU0) already exists!
        by __kmalloc_track_caller+25
        last touched by __kmalloc_track_caller
Allocation #83740 (CPU0) already exists!
        by __kmalloc_track_caller+25
        last touched by __kmalloc_track_caller

For my purpose, I would like to trace how and where is memory
allocated - just one one single userspace program which access the
mmap("/dev/mem") to read the memory.   How can it be done?   "Tracing
memory" in my context will mean list all the kernel-function +
memory-allocated-within-the-function + its-PFN-or-PTE-information (to
pinpoint the exact physical page).   My understanding is that these
can be done, via checking the value of "current", as each userspace
program started will have a unique "current" context value, and
therefore within any kernel function, just check this value, to focus
tracing on just one particular userspace program.   Correct?

d.   The following:

/sys/kernel/debug/kmemtrace>ls -al
总计 0
drwxr-xr-x 2 root root          0 2008-10-25 .
drwxr-xr-x 9 root root          0 2008-10-25 ..
-r-------- 1 root root          0 2008-10-25 abi_version
-r-------- 1 root root 2946936192 2008-10-25 cpu0
-r-------- 1 root root 1701263952 2008-10-25 cpu1
-rw------- 1 root root          0 2008-10-25 enabled
-r-------- 1 root root          0 2008-10-25 total_overruns

So the information is stored in memory, right?   Is it possible to
reset it?   I don't want these information to clog up the memory.

e.   The balance between cpu0 and cpu1 does not seemed equal, any
implications on the scheduler/ IO Scheduler?   or memory allocation
scheduler (if there exists one :-))....sorry about that....my
knowledge is limited.

On Fri, Oct 24, 2008 at 10:15 PM, Pekka Enberg <penberg@...helsinki.fi> wrote:
> On Fri, 2008-10-24 at 12:44 +0800, Peter Teoh wrote:
>> after doing a
>>
>> git clone git://repo.or.cz/linux-2.6/kmemtrace.git
>>
>> I reboot the OS and encountered several application crashes.....the
>> logs are as per attached....please comment.
>>
>> for bug0 and bug1, the system go into a state of complete
>> non-responsive, even connecting via SSH into the system becomes
>> impossible, and bug0 and bug1 was generated just before it goes into
>> this state.
>>
>> for bug2, the mouse seemed to respond, i managed to output the dmesg
>> (which is bug2 itself).
>>
>> any comments?
>
> Hmm, you're hitting out-of-memory. I can't immediately see how kmemtrace
> is at fault here. Eduard, thoughts?
>
>



-- 
Regards,
Peter Teoh

Powered by blists - more mailing lists