linux-kernel - Re: [PATCH v9 06/13] task_isolation: add debug boot flag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<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/