From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751967AbcERRHF (ORCPT <rfc822;w@1wt.eu>);
	Wed, 18 May 2016 13:07:05 -0400
Received: from bombadil.infradead.org ([198.137.202.9]:47824 "EHLO
	bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932276AbcERRHB (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 18 May 2016 13:07:01 -0400
Date: Wed, 18 May 2016 19:06:47 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Chris Metcalf <cmetcalf@mellanox.com>
Cc: Gilad Ben Yossef <giladb@ezchip.com>, Steven Rostedt <rostedt@goodmis.org>,
        Ingo Molnar <mingo@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Rik van Riel <riel@redhat.com>, Tejun Heo <tj@kernel.org>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Christoph Lameter <cl@linux.com>,
        Viresh Kumar <viresh.kumar@linaro.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will.deacon@arm.com>,
        Andy Lutomirski <luto@amacapital.net>, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v12 07/13] task_isolation: add debug boot flag
Message-ID: <20160518170647.GL3193@twins.programming.kicks-ass.net>
References: <1459877922-15512-1-git-send-email-cmetcalf@mellanox.com>
 <1459877922-15512-8-git-send-email-cmetcalf@mellanox.com>
 <20160518135645.GJ3193@twins.programming.kicks-ass.net>
 <684587d7-3653-7570-215f-37d3e9e786bc@mellanox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <684587d7-3653-7570-215f-37d3e9e786bc@mellanox.com>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, May 18, 2016 at 12:35:19PM -0400, Chris Metcalf wrote:
> On 5/18/2016 9:56 AM, Peter Zijlstra wrote:
> >On Tue, Apr 05, 2016 at 01:38:36PM -0400, Chris Metcalf wrote:
> >>+#ifdef CONFIG_TASK_ISOLATION
> >>+void task_isolation_debug(int cpu)
> >>+{
> >>+	struct task_struct *p;
> >>+
> >>+	if (!task_isolation_possible(cpu))
> >>+		return;
> >>+
> >>+	rcu_read_lock();
> >>+	p = cpu_curr(cpu);
> >>+	get_task_struct(p);
> >>+	rcu_read_unlock();
> >>+	task_isolation_debug_task(cpu, p);
> >>+	put_task_struct(p);
> >
> >This is still broken...
> 
> I don't know how or why, though. :-)  Can you give me a better idiom?
> This looks to my eye just like how it's done for something like
> sched_setaffinity() by one task on another task, and I would have
> assumed the risks there of the other task evaporating part way
> through would be the same as the risks here.

Because rcu_read_lock() does not stop the task pointed to by
cpu_curr(cpu) from disappearing on you entirely.

See also the discussion around:

lkml.kernel.org/r/20160518170218.GY3192@twins.programming.kicks-ass.net