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
| ||
|
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