This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Thanks
Prasanna
-- 
Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Email: prasanna@in.ibm.com
Ph: 91-80-25044636


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]