On Mon, 4 Jan 2016 18:42:00 -0500
Chris Metcalf <cmetc...@ezchip.com> wrote:
> On 1/4/2016 5:52 PM, Steven Rostedt wrote:
> > On Mon, 4 Jan 2016 14:34:44 -0500
> > Chris Metcalf<cmetc...@ezchip.com> wrote:
> >
> >
> >> >+#ifdef CONFIG_TASK_ISOLATION
> >> >+void task_isolation_debug(int cpu)
> >> >+{
> >> >+ struct task_struct *p;
> >> >+
> >> >+ if (!task_isolation_possible(cpu))
> >> >+ return;
> >> >+
> >> >+ rcu_read_lock();
> > What's the rcu_read_lock() for? I don't see what is being protected by
> > rcu here?
>
> I'm not completely clear either, but this is the same idiom as is used
> throughout
> kernel/sched/core.c when mapping from a pid or a cpu to a task_struct, since
> obviously you could end up racing with the task_struct being removed after the
> task dies. My best understanding is that the rcu_read_lock() holds up the
> final
> free of the structure so that we have time here to get another reference to
> it.
>
> See for example sched_setaffinity() for a similar use of the idiom.
>
Ah you're right. I'm still trying to get back up to speed from the
holidays. Yeah, we need to grab the lock to prevent the task from going
away from the time we get cpu_curr() to the time we up it's ref count.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
