[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160105084235.10ad5ff2@gandalf.local.home>
Date: Tue, 5 Jan 2016 08:42:35 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Chris Metcalf <cmetcalf@...hip.com>
Cc: Gilad Ben Yossef <giladb@...hip.com>,
Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Rik van Riel <riel@...hat.com>, Tejun Heo <tj@...nel.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Christoph Lameter <cl@...ux.com>,
Viresh Kumar <viresh.kumar@...aro.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
Andy Lutomirski <luto@...capital.net>,
<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v9 06/13] task_isolation: add debug boot flag
On Mon, 4 Jan 2016 18:42:00 -0500
Chris Metcalf <cmetcalf@...hip.com> wrote:
> On 1/4/2016 5:52 PM, Steven Rostedt wrote:
> > On Mon, 4 Jan 2016 14:34:44 -0500
> > Chris Metcalf<cmetcalf@...hip.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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists