public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* do_mmap fails to work on RHEL5.1GA
@ 2007-12-18  0:53 baiwd
  0 siblings, 0 replies; 4+ messages in thread
From: baiwd @ 2007-12-18  0:53 UTC (permalink / raw)
  To: systemtap

Hello:
    When I test with the newest stp on RHEL5.1GA, I  found that probe 
for do_mmap in memory.stp
cannot work correctly. It reported:
Pass 1: parsed user script and 38 library script(s) in 
306usr/4sys/325real ms.
Pass 2: analyzed script: 14 probe(s), 0 function(s), 0 embed(s), 0 
global(s) in 1076usr/97sys/1172real ms.
Pass 3: translated to C into 
"/tmp/stapLlRNuv/stap_5a545779c7b8d4c8da640eed3f8c78f8_2314.c" in 
1usr/0sys/1real ms.
Pass 4: compiled C into "stap_5a545779c7b8d4c8da640eed3f8c78f8_2314.ko" 
in 4715usr/245sys/4710real ms.
Pass 5: starting run.
ERROR: probe kernel.function("do_mmap@include/linux/mm.h:1001") 
registration error (rc -22)
     By looking through the elf file of linux kernel debug and the 
source codes, I think do_mmap and do_mmap2
are inlined functions, and they maybe inlined in optimization. But I 
find that do_mmap and do_mmap2 in all the
versions use do_mmap_pgoff which is not inlined and use almost the same 
arguments as do_mmap and do_mmap2.
So I wondered whether memory.stp can be changed as following:

--- memory.stp.old 2007-12-12 14:14:46.000000000 +0900
+++ memory.stp 2007-12-12 14:40:52.000000000 +0900
@@ -112,7 +112,7 @@ probe vm.write_shared_copy = kernel.func
* address - the requested address
* length - the length of the memory segment
*/
-probe vm.mmap = kernel.function("do_mmap"), kernel.function("do_mmap2")? {
+probe vm.mmap = kernel.function("do_mmap_pgoff") {
address = $addr
length = $len
}


 From Bai Weidong <baiwd@cn.fujitsu.com>
Best Regards

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: do_mmap fails to work on RHEL5.1GA
  2007-12-18  3:29 ` Frank Ch. Eigler
@ 2007-12-18  5:47   ` baiwd
  0 siblings, 0 replies; 4+ messages in thread
From: baiwd @ 2007-12-18  5:47 UTC (permalink / raw)
  To: systemtap

Frank:
Frank Ch. Eigler wrote:
> baiwd <baiwd@cn.fujitsu.com> writes:
>
>   
>> When I test with the newest stp on RHEL5.1GA, I found that probe for
>> do_mmap in memory.stp cannot work correctly. [...]
>>     
>
> This means that systemtap got addresses it thought plausible, but the
> kernel refused to actually insert a probe there.  I wonder if this is
> the latent systemtap bug awakened by elfutils 0.131.
>   
>
> This would be a good candidate for the recently added optional/sufficient flag:
>
> probe vm.mmap = kernel.function("do_mmap")!,
>                 kernel.function("do_mmap_pgoff")!,
>                 kernel.function("do_mmap2") { ... }
>   
         Thank you for your directions. From the following reports, I 
think the problem is not in
tapset. You are right. The kernel seems to refuse to insert a probe there.

Pass 1: parsed user script and 38 library script(s) in 
306usr/4sys/312real ms.
probe do_brk@mm/mmap.c:1961 kernel section=.text pc=0xa00000010012c760
probe do_mmap@include/linux/mm.h:1001 kernel section=.text 
pc=0xa0000001001afaa0probe do_mmap@include/linux/mm.h:1001 kernel 
section=.text pc=0xa0000001001cddc0probe do_mmap@include/linux/mm.h:1001 
kernel section=.text pc=0xa0000001001cde90probe 
do_mmap@include/linux/mm.h:1001 kernel section=.text 
pc=0xa0000001001ce211probe do_mmap@include/linux/mm.h:1001 kernel 
section=.text pc=0xa0000001001d0940probe do_mmap@include/linux/mm.h:1001 
kernel section=.text pc=0xa00000010022bb40Probe point 
kernel.function("do_mmap")! sufficient, skipped 
kernel.function("do_mmap_pgoff")! kernel.function("do_mmap2")probe 
do_munmap@mm/mmap.c:1874 kernel section=.text pc=0xa00000010012b340
probe __oom_kill_task@mm/oom_kill.c:265 kernel section=.text 
pc=0xa000000100104c40probe __handle_mm_fault@mm/memory.c:2574 kernel 
section=.text pc=0xa000000100123000probe do_wp_page@mm/memory.c:1622 
kernel section=.text pc=0xa00000010011e720
probe __handle_mm_fault@mm/memory.c:2574 kernel section=.text 
pc=0xa000000100123000Pass 2: analyzed script: 12 probe(s), 0 
function(s), 0 embed(s), 0 global(s) in 988usr/102sys/1099real ms.
Pass 3: using cached 
/root/.systemtap/cache/e2/stap_e21b079aada2c0de4695a0eb4bfdf705_2188.cPass 
4: using cached 
/root/.systemtap/cache/e2/stap_e21b079aada2c0de4695a0eb4bfdf705_2188.koPass 
5: starting run.
Running /usr/bin/staprun -v -d 8500 
/tmp/stapQZYd3a/stap_e21b079aada2c0de4695a0eb4bfdf705_2188.koERROR: 
probe kernel.function("do_mmap@include/linux/mm.h:1001") registration 
error (rc -22)stapio:cleanup_and_exit:216 CLEANUP AND EXIT  closed=1
stapio:cleanup_and_exit:229 closing control channel
Pass 5: run completed in 27usr/78sys/128real ms.
Running rm -rf /tmp/stapQZYd3a


Best Regards
Bai Weidong

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: do_mmap fails to work on RHEL5.1GA
  2007-12-18  0:58 baiwd
@ 2007-12-18  3:29 ` Frank Ch. Eigler
  2007-12-18  5:47   ` baiwd
  0 siblings, 1 reply; 4+ messages in thread
From: Frank Ch. Eigler @ 2007-12-18  3:29 UTC (permalink / raw)
  To: baiwd; +Cc: systemtap

baiwd <baiwd@cn.fujitsu.com> writes:

> When I test with the newest stp on RHEL5.1GA, I found that probe for
> do_mmap in memory.stp cannot work correctly. [...]

Thanks for testing!

> ERROR: probe kernel.function("do_mmap@include/linux/mm.h:1001")
> registration error (rc -22)

This means that systemtap got addresses it thought plausible, but the
kernel refused to actually insert a probe there.  I wonder if this is
the latent systemtap bug awakened by elfutils 0.131.

> By looking through the elf file of linux kernel debug and the source
> codes, I think do_mmap and do_mmap2 are inlined functions [...]

That by itself is not a problem.  We can often find reasonable probing
addresses for inlined functions.  (Not being able to get at their
parameters is a whole different (gcc) problem.)


> So I wondered whether memory.stp can be changed as following:
> [...]
> -probe vm.mmap = kernel.function("do_mmap"), kernel.function("do_mmap2")? {
> +probe vm.mmap = kernel.function("do_mmap_pgoff") {

This would be a good candidate for the recently added optional/sufficient flag:

probe vm.mmap = kernel.function("do_mmap")!,
                kernel.function("do_mmap_pgoff")!,
                kernel.function("do_mmap2") { ... }

- FChE

^ permalink raw reply	[flat|nested] 4+ messages in thread

* do_mmap fails to work on RHEL5.1GA
@ 2007-12-18  0:58 baiwd
  2007-12-18  3:29 ` Frank Ch. Eigler
  0 siblings, 1 reply; 4+ messages in thread
From: baiwd @ 2007-12-18  0:58 UTC (permalink / raw)
  To: systemtap

Hello:
     When I test with the newest stp on RHEL5.1GA, I  found that probe 
for do_mmap in memory.stp
cannot work correctly. It reported:
Pass 1: parsed user script and 38 library script(s) in 
306usr/4sys/325real ms.
Pass 2: analyzed script: 14 probe(s), 0 function(s), 0 embed(s), 0 
global(s) in 1076usr/97sys/1172real ms.
Pass 3: translated to C into 
"/tmp/stapLlRNuv/stap_5a545779c7b8d4c8da640eed3f8c78f8_2314.c" in 
1usr/0sys/1real ms.
Pass 4: compiled C into "stap_5a545779c7b8d4c8da640eed3f8c78f8_2314.ko" 
in 4715usr/245sys/4710real ms.
Pass 5: starting run.
ERROR: probe kernel.function("do_mmap@include/linux/mm.h:1001") 
registration error (rc -22)
      By looking through the elf file of linux kernel debug and the 
source codes, I think do_mmap and do_mmap2
are inlined functions, and they maybe inlined in optimization. But I 
find that do_mmap and do_mmap2 in all the
versions use do_mmap_pgoff which is not inlined and use almost the same 
arguments as do_mmap and do_mmap2.
So I wondered whether memory.stp can be changed as following:

--- memory.stp.old 2007-12-12 14:14:46.000000000 +0900
+++ memory.stp 2007-12-12 14:40:52.000000000 +0900
@@ -112,7 +112,7 @@ probe vm.write_shared_copy = kernel.func
* address - the requested address
* length - the length of the memory segment
*/
-probe vm.mmap = kernel.function("do_mmap"), kernel.function("do_mmap2")? {
+probe vm.mmap = kernel.function("do_mmap_pgoff") {
address = $addr
length = $len
}


 From Bai Weidong <baiwd@cn.fujitsu.com>
Best Regards

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-12-18  5:47 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-12-18  0:53 do_mmap fails to work on RHEL5.1GA baiwd
2007-12-18  0:58 baiwd
2007-12-18  3:29 ` Frank Ch. Eigler
2007-12-18  5:47   ` baiwd

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).