This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Review patches of user space kprobe
- From: Prasanna S Panchamukhi <prasanna at in dot ibm dot com>
- To: "Zhang, Yanmin" <yanmin dot zhang at intel dot com>
- Cc: systemtap at sources dot redhat dot com, "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>, "Mao, Bibo" <bibo dot mao at intel dot com>
- Date: Fri, 6 Jan 2006 15:56:09 +0530
- Subject: Re: Review patches of user space kprobe
- References: <8126E4F969BA254AB43EA03C59F44E84046927C4@pdsmsx404>
- Reply-to: prasanna at in dot ibm dot com
> >>> >>If vma's are temporarily defined, then readpage hooks should walk
> >>> >>through the vma list to get the vma. To reduce the time spent in
> >>> >>readpage/readpages hooks in fastpath, we store it while registeration.
> >>> Incorrect. This vma only represents one process who maps the page. How about other processes who map the same page?
> >>
> >>Do you mean the same page is mapped in different vma?
> Map the page in different vma of different processes (address spaces). I think it's common. For example, libc.so is mapped to many processes. Every process has its own vma to map the page.
>
I think the dll's share the same vma's.
below is the output of different process libc mmaps.
./1/maps:006fd000-0082f000 r-xp 00000000 03:02 395614 /lib/tls/libc-2.3.2.so
./1/maps:0082f000-00832000 rw-p 00132000 03:02 395614 /lib/tls/libc-2.3.2.so
./1996/maps:006fd000-0082f000 r-xp 00000000 03:02 395614 /lib/tls/libc-2.3.2.so
./1996/maps:0082f000-00832000 rwxp 00132000 03:02 395614 /lib/tls/libc-2.3.2.so
./2000/maps:006fd000-0082f000 r-xp 00000000 03:02 395614 /lib/tls/libc-2.3.2.so
./2000/maps:0082f000-00832000 rwxp 00132000 03:02 395614 /lib/tls/libc-2.3.2.so
./2011/maps:006fd000-0082f000 r-xp 00000000 03:02 395614 /lib/tls/libc-2.3.2.so
./2011/maps:0082f000-00832000 rwxp 00132000 03:02 395614 /lib/tls/libc-2.3.2.so
./.2014/maps:006fd000-0082f000 r-xp 00000000 03:02 395614 /lib/tls/libc-2.3.2.so
./.2014/maps:0082f000-00832000 rwxp 00132000 03:02 395614 /lib/tls/libc-2.3.2.so
./2031/maps:006fd000-0082f000 r-xp 00000000 03:02 395614 /lib/tls/libc-2.3.2.so
./2031/maps:0082f000-00832000 rwxp 00132000 03:02 395614 /lib/tls/libc-2.3.2.so
./2032/maps:006fd000-0082f000 r-xp 00000000 03:02 395614 /lib/tls/libc-2.3.2.so
./2032/maps:0082f000-00832000 rwxp 00132000 03:02 395614 /lib/tls/libc-2.3.2.so
./2033/maps:006fd000-0082f000 r-xp 00000000 03:02 395614 /lib/tls/libc-2.3.2.so
./2033/maps:0082f000-00832000 rwxp 00132000 03:02 395614 /lib/tls/libc-2.3.2.so
./2034/maps:006fd000-0082f000 r-xp 00000000 03:02 395614 /lib/tls/libc-2.3.2.so
./2034/maps:0082f000-00832000 rwxp 00132000 03:02 395614 /lib/tls/libc-2.3.2.so
./2035/maps:006fd000-0082f000 r-xp 00000000 03:02 395614 /lib/tls/libc-2.3.2.so
./2035/maps:0082f000-00832000 rwxp 00132000 03:02 395614 /lib/tls/libc-2.3.2.so
./2397/maps:006fd000-0082f000 r-xp 00000000 03:02 395614 /lib/tls/libc-2.3.2.so
> >>
> >>This is done to make use of register_kprobe(), the address returned by
> >>kmap_atomic is passed to register_kprobe() and even though the kernel data
> >>address is stored at kp.addr, that is enough to distinguish between
> >>kernel probes.
> Is it true on all arch? I don't think it's safe to do so. Actually, register_kprobe just needs know it's a uprobe.
yes, otherwise need to find out a way to pass the mapped address to register_kprobe(). All this can be avoided
if register_kprobe() is bypassed :).
Thanks
Prasanna
--
Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Email: prasanna@in.ibm.com
Ph: 91-80-25044636