From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Peter Zijlstra <peterz@infradead.org>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
utrace-devel <utrace-devel@redhat.com>,
Mark Wielaard <mjw@redhat.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Masami Hiramatsu <mhiramat@redhat.com>,
Maneesh Soni <maneesh@in.ibm.com>,
Jim Keniston <jkenisto@us.ibm.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] [PATCH 4/7] Uprobes Implementation
Date: Tue, 12 Jan 2010 13:51:28 +0530 [thread overview]
Message-ID: <20100112082128.GA22420@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100112020155.GC10869@linux.vnet.ibm.com>
Hi Paul,
> > +
> > +/*
> > + * Allocate a uprobe_task object for p and add it to uproc's list.
> > + * Called with p "got" and uproc->rwsem write-locked. Called in one of
> > + * the following cases:
> > + * - before setting the first uprobe in p's process
> > + * - we're in uprobe_report_clone() and p is the newly added thread
> > + * Returns:
> > + * - pointer to new uprobe_task on success
> > + * - NULL if t dies before we can utrace_attach it
> > + * - negative errno otherwise
> > + */
> > +static struct uprobe_task *uprobe_add_task(struct pid *p,
> > + struct uprobe_process *uproc)
> > +{
> > + struct uprobe_task *utask;
> > + struct utrace_engine *engine;
> > + struct task_struct *t = pid_task(p, PIDTYPE_PID);
>
> What keeps the task_struct referenced by "t" from disappearing at this
> point?
We have a ref-counted pid which is used for creation of the utrace
engine. If the task_struct disappears then utrace would refuse to create
an engine and we wouldnt proceed further. We only use the task struct
and pid only when we have a successful utrace engine. Once utrace
engine is created,utrace guarantees us that the task will remain till
Uprobes is notified of the death/exit.
>
> > +
> > + if (!t)
> > + return NULL;
> > + utask = kzalloc(sizeof *utask, GFP_USER);
> > + if (unlikely(utask == NULL))
> > + return ERR_PTR(-ENOMEM);
> > +
> > + utask->pid = p;
> > + utask->tsk = t;
> > + utask->state = UPTASK_RUNNING;
> > + utask->quiescing = false;
> > + utask->uproc = uproc;
> > + utask->active_probe = NULL;
> > + utask->doomed = false;
> > + INIT_LIST_HEAD(&utask->deferred_registrations);
> > + INIT_LIST_HEAD(&utask->delayed_signals);
> > + INIT_LIST_HEAD(&utask->list);
> > + list_add_tail(&utask->list, &uproc->thread_list);
> > + uprobe_hash_utask(utask);
> > +
> > + engine = utrace_attach_pid(p, UTRACE_ATTACH_CREATE,
> > + p_uprobe_utrace_ops, utask);
> > + if (IS_ERR(engine)) {
> > + long err = PTR_ERR(engine);
> > + printk("uprobes: utrace_attach_task failed, returned %ld\n",
> > + err);
> > + uprobe_free_task(utask, 0);
> > + if (err == -ESRCH)
> > + return NULL;
> > + return ERR_PTR(err);
> > + }
> > + goto dont_add;
> > + list_for_each_entry(utask, &uproc->thread_list, list) {
>
> Doesn't this need to be list_for_each_entry_rcu()?
>
> Or do you have ->thread_list protected elsewise?
thread_list is protected by write lock for uproc->rwsem.
>
> > + if (utask->tsk == t)
> > + /* Already added */
> > + goto dont_add;
> > + }
> > + /* Found thread/task to add. */
> > + pid = get_pid(task_pid(t));
> > + break;
> > +dont_add:
> > + t = next_thread(t);
> > + } while (t != start);
> > + }
> > + rcu_read_unlock();
>
> Now that we are outside of rcu_read_lock()'s protection, the task
> indicated by "pid" might disappear, and the value of "pid" might well
> be reused. Is this really OK?
We have a ref-counted pid; so pid should ideally not disappear.
And as I said earlier, once utrace engine gets created, we are sure that
the task struct lies till the engine gets detached. If an engine is not
created, we dont use the task struct or the pid. We piggyback on the
guarantee that utrace provides.
>
> > + return pid;
> > +}
> > +
> > +/*
> > + * Given a numeric thread ID, return a ref-counted struct pid for the
> > + * task-group-leader thread.
> > + */
> > +static struct pid *uprobe_get_tg_leader(pid_t p)
> > +{
> > + struct pid *pid = NULL;
> > +
> > + rcu_read_lock();
> > + if (current->nsproxy)
> > + pid = find_vpid(p);
> > + if (pid) {
> > + struct task_struct *t = pid_task(pid, PIDTYPE_PID);
> > + if (t)
> > + pid = task_tgid(t);
> > + else
> > + pid = NULL;
> > + }
> > + rcu_read_unlock();
>
> What happens if the thread disappears at this point? We are outside of
> rcu_read_lock() protection, so all the structures could potentially be
> freed up by other CPUs, especially if this CPU takes an interrupt or is
> preempted.
>
> > + return get_pid(pid); /* null pid OK here */
> > +}
Same as above ;
> > +/*
> > + * Signal callback:
> > + */
> > +static u32 uprobe_report_signal(u32 action,
> > + struct utrace_engine *engine,
> > + struct pt_regs *regs,
> > + siginfo_t *info,
> > + const struct k_sigaction *orig_ka,
> > + struct k_sigaction *return_ka)
> > +{
> > + struct uprobe_task *utask;
> > + struct uprobe_process *uproc;
> > + bool doomed;
> > + enum utrace_resume_action report_action;
> > +
> > + utask = (struct uprobe_task *)rcu_dereference(engine->data);
>
> Are we really in an RCU read-side critical section here?
Yeah we dont need the rcu_deference here.
>
> > +static u32 uprobe_report_quiesce(u32 action,
> > + struct utrace_engine *engine,
> > + unsigned long event)
> > +{
> > + struct uprobe_task *utask;
> > + struct uprobe_process *uproc;
> > + bool done_quiescing = false;
> > +
> > + utask = (struct uprobe_task *)rcu_dereference(engine->data);
>
> Are we really in an RCU read-side critical section here?
Yeah we dont need the rcu_deference here also.
>
> > +
> > +static u32 uprobe_exec_exit(struct utrace_engine *engine,
> > + struct task_struct *tsk, int exit)
> > +{
> > + struct uprobe_process *uproc;
> > + struct uprobe_probept *ppt;
> > + struct uprobe_task *utask;
> > + bool utask_quiescing;
> > +
> > + utask = (struct uprobe_task *)rcu_dereference(engine->data);
>
> Are we really in an RCU read-side critical section here?
Yeah we dont need the rcu_deference here also.
>
> > + * - Provide option for child to inherit uprobes.
> > + */
> > +static u32 uprobe_report_clone(u32 action,
> > + struct utrace_engine *engine,
> > + unsigned long clone_flags,
> > + struct task_struct *child)
> > +{
> > + struct uprobe_process *uproc;
> > + struct uprobe_task *ptask, *ctask;
> > +
> > + ptask = (struct uprobe_task *)rcu_dereference(engine->data);
>
> Are we really in an RCU read-side critical section here?
Yeah we dont need the rcu_deference here also.
--
Thanks and Regards
Srikar
next prev parent reply other threads:[~2010-01-12 8:21 UTC|newest]
Thread overview: 158+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-11 12:25 [RFC] [PATCH 0/7] UBP, XOL and Uprobes Srikar Dronamraju
2010-01-11 12:25 ` [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP) Srikar Dronamraju
2010-01-14 11:08 ` Peter Zijlstra
2010-01-14 19:46 ` Jim Keniston
2010-01-15 9:02 ` Peter Zijlstra
2010-01-15 21:07 ` Jim Keniston
2010-01-15 21:49 ` Peter Zijlstra
2010-01-16 0:58 ` Jim Keniston
2010-01-16 10:33 ` Peter Zijlstra
2010-01-17 0:12 ` Bryan Donlan
2010-01-18 7:37 ` Peter Zijlstra
2010-01-17 14:37 ` Avi Kivity
2010-01-15 9:03 ` Peter Zijlstra
2010-01-15 9:38 ` Ananth N Mavinakayanahalli
2010-01-15 9:50 ` Peter Zijlstra
2010-01-15 10:10 ` Ananth N Mavinakayanahalli
2010-01-15 10:13 ` Peter Zijlstra
2010-01-15 10:22 ` Ananth N Mavinakayanahalli
2010-01-15 10:56 ` Peter Zijlstra
2010-01-15 11:02 ` Peter Zijlstra
2010-01-15 21:19 ` Jim Keniston
2010-01-17 14:39 ` Avi Kivity
2010-01-17 14:52 ` Peter Zijlstra
2010-01-17 14:56 ` Avi Kivity
2010-01-17 15:01 ` Peter Zijlstra
2010-01-20 12:55 ` Pavel Machek
2010-01-17 14:59 ` Avi Kivity
2010-01-17 15:03 ` Peter Zijlstra
2010-01-17 19:33 ` Avi Kivity
2010-01-18 7:45 ` Peter Zijlstra
2010-01-18 11:01 ` Avi Kivity
2010-01-18 11:44 ` Peter Zijlstra
2010-01-18 12:01 ` Avi Kivity
2010-01-18 12:06 ` Peter Zijlstra
2010-01-18 12:09 ` Avi Kivity
2010-01-18 12:13 ` Pekka Enberg
2010-01-18 12:17 ` Avi Kivity
2010-01-18 12:24 ` Peter Zijlstra
2010-01-18 12:24 ` Pekka Enberg
2010-01-18 12:44 ` Srikar Dronamraju
2010-01-18 12:51 ` Pekka Enberg
2010-01-18 12:53 ` Avi Kivity
2010-01-18 12:57 ` Pekka Enberg
2010-01-18 13:06 ` Avi Kivity
2010-01-18 22:15 ` Jim Keniston
2010-01-19 8:07 ` Avi Kivity
2010-01-19 17:47 ` Jim Keniston
2010-01-19 18:06 ` Frederic Weisbecker
2010-01-20 6:36 ` Srikar Dronamraju
2010-01-20 10:51 ` Frederic Weisbecker
2010-01-20 19:31 ` Masami Hiramatsu
2010-01-20 9:43 ` Avi Kivity
2010-01-20 9:57 ` Peter Zijlstra
2010-01-20 12:22 ` Avi Kivity
2010-01-27 8:24 ` Ingo Molnar
2010-01-27 8:35 ` Avi Kivity
2010-01-27 9:08 ` Ingo Molnar
2010-01-27 9:25 ` Avi Kivity
2010-01-27 10:23 ` Ingo Molnar
2010-02-07 13:47 ` Avi Kivity
2010-01-20 10:45 ` Srikar Dronamraju
2010-01-20 12:23 ` Avi Kivity
2010-01-20 18:31 ` Andi Kleen
2010-01-20 19:34 ` Jim Keniston
2010-01-20 19:58 ` Andi Kleen
2010-01-20 20:28 ` Jim Keniston
2010-01-18 13:05 ` Peter Zijlstra
2010-01-18 13:34 ` Mark Wielaard
2010-01-18 19:49 ` Jim Keniston
2010-01-18 15:43 ` Ananth N Mavinakayanahalli
2010-01-18 16:52 ` Avi Kivity
2010-01-18 17:10 ` Ananth N Mavinakayanahalli
2010-01-18 12:14 ` Peter Zijlstra
2010-01-18 12:37 ` Avi Kivity
2010-01-18 13:15 ` Peter Zijlstra
2010-01-18 13:33 ` Avi Kivity
2010-01-18 13:34 ` K.Prasad
2010-01-20 15:57 ` Mel Gorman
2010-01-20 18:32 ` Andi Kleen
2010-01-18 11:45 ` Peter Zijlstra
2010-01-11 12:25 ` [RFC] [PATCH 2/7] x86 support for UBP Srikar Dronamraju
2010-01-11 12:25 ` [RFC] [PATCH 3/7] Execution out of line (XOL) Srikar Dronamraju
2010-01-14 11:08 ` Peter Zijlstra
2010-01-14 22:43 ` Jim Keniston
2010-01-15 9:07 ` Peter Zijlstra
2010-01-15 11:12 ` Srikar Dronamraju
2010-01-15 20:18 ` Jim Keniston
2010-01-11 12:25 ` [RFC] [PATCH 4/7] Uprobes Implementation Srikar Dronamraju
2010-01-12 2:01 ` Paul E. McKenney
2010-01-12 8:21 ` Srikar Dronamraju [this message]
2010-01-12 5:36 ` Frederic Weisbecker
2010-01-12 8:14 ` Ananth N Mavinakayanahalli
2010-01-13 0:53 ` Jim Keniston
2010-01-14 11:12 ` Peter Zijlstra
2010-01-12 8:54 ` Srikar Dronamraju
2010-01-14 11:09 ` Peter Zijlstra
2010-01-14 22:49 ` Jim Keniston
2010-01-15 9:10 ` Peter Zijlstra
2010-01-15 9:26 ` Frank Ch. Eigler
2010-01-15 9:35 ` Peter Zijlstra
2010-01-15 13:10 ` Frank Ch. Eigler
2010-01-15 13:25 ` Peter Zijlstra
2010-01-15 13:38 ` Frank Ch. Eigler
2010-01-15 13:47 ` Peter Zijlstra
2010-01-15 14:00 ` Frank Ch. Eigler
2010-01-15 14:06 ` Peter Zijlstra
2010-01-15 14:22 ` Frank Ch. Eigler
2010-01-15 14:40 ` Peter Zijlstra
2010-01-15 14:20 ` Srikar Dronamraju
2010-01-15 14:25 ` Peter Zijlstra
2010-01-15 23:11 ` Jim Keniston
2010-01-16 15:50 ` Frank Ch. Eigler
2010-01-15 10:26 ` Srikar Dronamraju
2010-01-15 10:33 ` Peter Zijlstra
2010-01-15 11:05 ` Maneesh Soni
2010-01-15 11:12 ` Peter Zijlstra
2010-01-15 11:18 ` Peter Zijlstra
2010-01-15 22:27 ` Jim Keniston
2010-01-15 23:44 ` Jim Keniston
2010-01-16 10:04 ` Peter Zijlstra
2010-01-15 13:08 ` Srikar Dronamraju
2010-01-15 13:16 ` Peter Zijlstra
2010-01-15 13:38 ` Peter Zijlstra
2010-01-11 12:25 ` [RFC] [PATCH 5/7] X86 Support for Uprobes Srikar Dronamraju
2010-01-14 11:13 ` Peter Zijlstra
2010-01-14 23:07 ` Jim Keniston
2010-01-11 12:26 ` [RFC] [PATCH 6/7] Uprobes Documentation Srikar Dronamraju
2010-01-11 12:26 ` [RFC] [PATCH 7/7] Ftrace plugin for Uprobes Srikar Dronamraju
2010-01-12 4:54 ` Frederic Weisbecker
2010-01-12 5:08 ` Steven Rostedt
2010-01-12 5:44 ` Frederic Weisbecker
2010-01-12 19:12 ` Tim Bird
2010-01-13 21:58 ` Masami Hiramatsu
2010-01-13 22:12 ` Masami Hiramatsu
2010-01-13 23:36 ` Steven Rostedt
2010-01-12 18:54 ` Frank Ch. Eigler
2010-01-12 22:00 ` Masami Hiramatsu
2010-01-12 22:15 ` Frank Ch. Eigler
2010-01-12 22:30 ` Masami Hiramatsu
2010-01-14 11:23 ` Peter Zijlstra
2010-01-14 11:29 ` Peter Zijlstra
2010-01-14 12:16 ` Mark Wielaard
2010-01-14 12:19 ` Peter Zijlstra
2010-01-14 11:35 ` Frederic Weisbecker
2010-01-14 11:43 ` Peter Zijlstra
2010-01-14 12:23 ` Frederic Weisbecker
2010-01-14 12:29 ` Peter Zijlstra
2010-01-18 13:00 ` Frederic Weisbecker
2010-01-11 14:35 ` [RFC] [PATCH 0/7] UBP, XOL and Uprobes Masami Hiramatsu
2010-01-11 22:59 ` Jim Keniston
2010-01-22 7:02 ` [RFC] [PATCH 0/7] UBP, XOL and Uprobes [ Summary of Comments and actions to be taken ] Srikar Dronamraju
2010-01-22 7:24 ` Ananth N Mavinakayanahalli
2010-01-22 10:47 ` Peter Zijlstra
2010-01-27 6:53 ` Peter Zijlstra
2010-01-27 8:24 ` Peter Zijlstra
2010-01-22 18:06 ` Peter Zijlstra
2010-01-22 18:36 ` Masami Hiramatsu
2010-01-22 23:55 ` Jim Keniston
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100112082128.GA22420@linux.vnet.ibm.com \
--to=srikar@linux.vnet.ibm.com \
--cc=acme@infradead.org \
--cc=ananth@in.ibm.com \
--cc=fweisbec@gmail.com \
--cc=jkenisto@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maneesh@in.ibm.com \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=mjw@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=utrace-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox