RE: Review patches of user space kprobe

["Zhang, Yanmin" <yanmin dot zhang at intel dot com>]

>>-----Original Message-----
>>From: Prasanna S Panchamukhi [mailto:prasanna@in.ibm.com]
>>Sent: 2006年1月6日 16:57
>>To: Zhang, Yanmin
>>Cc: systemtap@sources.redhat.com; Keshavamurthy, Anil S; Mao, Bibo
>>Subject: Re: Review patches of user space kprobe
>>
>>> >>>uprobes in uprobe_module. Uprobes just need keep its own specific info.
>>> >>
>>> >>inode and offset combination uniquely identifies individual user space
>>> >>probe,
>>> What does "individual user space probe" mean here?
>>>
>>
>>Here individual user space probe mean, the place where the breakpoint
>>instruction is inserted.
>>
>>>Any uprobe will be shared by all processes who map the same page. Right?
>>
>>that's right.
>>
>>>
>>>  hence when a probe is hit, combination inode and offset is used to
>>> >>identify each probe. Keeping inode pointer in struct uprobe clearly
>>> >>reflects this concept.
>>> What's the relationship between uprobe and uprobe_module? All uprobes linked by uprobe_module->ulist_head have the same inode, right?
>>If it's correct, why not to just include inode in uprobe_module?
>>
>>This can be done, but in such a case for every probe hit, the uprobe_module list much be traversed just to get the inode.
>>
>>> >>>>		struct vm_area_struct *vma;
>>> >>>Item page and vma are used temporarily. They are not used when the probe
>>> >>>is hit. To shrink struct uprobe, they could be deleted. A new super
>>> >>>struct could be defined to include struct uprobe, or always to search
>>> >>>them when they are needed. Application might be inserted huge uprobes.
>>> >>>It's better to keep the struct smaller.
>>> >>
>>> >>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.

>>As of now we are not supporting such cases.
>>
>>> >>understand what you mean by "assign a fixed address in user space"
>>> map_uprobe_page sets uprobe->kp.addr to address returned by kmap_atomic, then insert_probe_page will add offset to uprobe->kp.addr.
>>Later, register_kprobe uses uprobe->kp.addr to estimate if the address is in kernel text. Is it wrong? As for why you didn't hit it,
>>I think mostly now uprobe->kp.addr is pointing to the kernel data area, but it doesn't point to user space. Right?
>>
>>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.