This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: Review patches of user space kprobe
- From: "Zhang, Yanmin" <yanmin dot zhang at intel dot com>
- To: <prasanna at in dot ibm 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: Mon, 9 Jan 2006 10:06:12 +0800
- Subject: RE: Review patches of user space kprobe
>>-----Original Message-----
>>From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of Prasanna S Panchamukhi
>>Sent: 2006年1月6日 18:26
>>To: Zhang, Yanmin
>>Cc: systemtap@sources.redhat.com; Keshavamurthy, Anil S; Mao, Bibo
>>Subject: Re: Review patches of user space kprobe
>>> >>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 :).
It's a good solution if register_kprobe is bypassed.