Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1301173 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v9 06/13] task_isolation: add debug boot flag Steven Rostedt <rostedt@goodmis.org> - 2016-01-05 00:00 +0100
    Re: [PATCH v9 06/13] task_isolation: add debug boot flag Chris Metcalf <cmetcalf@ezchip.com> - 2016-01-05 00:50 +0100
      Re: [PATCH v9 06/13] task_isolation: add debug boot flag Steven Rostedt <rostedt@goodmis.org> - 2016-01-05 14:50 +0100

#1301173 — Re: [PATCH v9 06/13] task_isolation: add debug boot flag

On Mon, 4 Jan 2016 14:34:44 -0500
Chris Metcalf <cmetcalf@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?

-- Steve

> +	p = cpu_curr(cpu);
> +	get_task_struct(p);
> +	rcu_read_unlock();
> +	task_isolation_debug_task(cpu, p);
> +	put_task_struct(p);
> +}
> +#endif
> +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1301193

On 1/4/2016 5:52 PM, Steven Rostedt wrote:
> On Mon, 4 Jan 2016 14:34:44 -0500
> Chris Metcalf<cmetcalf@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.

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1301535

On Mon, 4 Jan 2016 18:42:00 -0500
Chris Metcalf <cmetcalf@ezchip.com> wrote:

> On 1/4/2016 5:52 PM, Steven Rostedt wrote:
> > On Mon, 4 Jan 2016 14:34:44 -0500
> > Chris Metcalf<cmetcalf@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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web