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: [2/3] Userspace probes prototype-take2


>>-----Original Message-----
>>From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of Zhang, Yanmin
>>Sent: 2006年2月15日 16:07
>>To: prasanna@in.ibm.com
>>Cc: systemtap@sources.redhat.com
>>Subject: RE: [2/3] Userspace probes prototype-take2
>>
>>>>-----Original Message-----
>>>>From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of Prasanna S Panchamukhi
>>>>Sent: 2006年2月8日 22:13
>>>>To: systemtap@sources.redhat.com
>>>>Subject: Re: [2/3] Userspace probes prototype-take2
>>>>
>>>>
>>>>This patch provides the feature to insert the probes on the pages
>>>>that are not present in the memory during registeration.
>>>>
>>>>To add readpage and readpages() hooks, two new elements
>>>>are added to uprobe_module object.
>>>>struct address_space_operations *ori_a_ops;
>>>>struct address_space_operations user_a_ops;
>>>>
>>>>User space probe also allows the probes to be inserted within the
>>>>pages even that are not present in the memory at the time of
>>>>registration. This is done by adding hooks to readpage and readpages
>>>>routines. During registration, the address space operation object is
>>>>modified by replacing with userspace probes's specific readpage and
>>>>readpages routines. So that when the pages are readinto the memory
>>>>through the readpage and readpages address space operations, the
>>>>probes can be automatically inserted into those pages. These user
>>>>space readpage and readpages routines internally call the original
>>>>readpage() and readpages() routines and then check if the probes are
>>>>to be added to these pages and then insert the probes on these pages.
>>After I double-checked it, I found a big problem. When readpage/readpages return,
>>it doesn't mean the page/pages are really already up-to-date. If the caller wants
>>to get up-to-date pages, it needs call lock_page or wait_on_page_locked to get the page lock.
>>I/O lower layer is asynchronous with the thread. Only when the device really finishes I/O,
>>Mostly, bio->bi_end_io is called to unlock the page and change its state to up-to-date.
[YM] I checked it again and found map_uprobe_page already does so.


>>
>>If we use lock_page or wait_on_page_locked to wait the I/O complete in uprobe_readpage/uprobe_readpages,
>>It looks like we might break the implied rule that the caller needs call lock_page
>>or wait_on_page_locked to wait the page up-to-date.
[YM] So how about this question?


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