This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: Patch [2/3] Userspace probes readpage hooks
- 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: Thu, 2 Feb 2006 15:26:29 +0800
- Subject: RE: Patch [2/3] Userspace probes readpage hooks
>>-----Original Message-----
>>From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of Prasanna S Panchamukhi
>>Sent: 2006年1月27日 21:13
>>To: Zhang, Yanmin
>>Cc: systemtap@sources.redhat.com; Keshavamurthy, Anil S; Mao, Bibo
>>Subject: Re: Patch [2/3] Userspace probes readpage hooks
>>
>>Yanmin,
>>
>>> >>+ */
>>> >>+static int __kprobes uprobe_readpages(struct file *file,
>>> >>+ struct address_space *mapping,
>>> >>+ struct list_head *pages, unsigned nr_pages)
>>> >>+{
>>> >>+ int retval = 0;
>>> >>+ struct page *page;
>>> >>+ struct uprobe_module *umodule;
>>> >>+ struct uprobe *uprobe = NULL;
>>> >>+ struct hlist_node *node;
>>> >>+
>>> >>+ mutex_lock(&uprobe_mutex);
>>> >>+
>>> >>+ umodule = get_module_by_inode(file->f_dentry->d_inode);
>>> >>+ if (!umodule) {
>>> [YM] The race condition is still not resolved.
>>
>>Could you please elaborate the race condition?
[YM] Scenario: There are 2 threads. The 1st is calling uprobe_readpages (from readpages path), while the 2nd one is unregistering the uprobe and uprobe_module. So before the 1st one is executing the mutex_lock, the 2nd one might already remove the uprobe_module, then, uprobe_readpages returns failure. Actually, the 1st should reexecutes the original readpages proc instead of returning failure when it couldn't find right uprobe_module.