linux-kernel - Re: [PATCH] sched: Update task->on_rq when tasks are moving between runqueues

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] [day] [month] [year] [list]

Date:	Mon, 2 Nov 2015 12:40:36 -0800
From:	Paul Turner <pjt@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Olav Haugan <ohaugan@...eaurora.org>,
	Ingo Molnar <mingo@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH] sched: Update task->on_rq when tasks are moving between runqueues

On Wed, Oct 28, 2015 at 6:58 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Wed, Oct 28, 2015 at 05:57:10PM -0700, Olav Haugan wrote:
>> On 15-10-25 11:09:24, Peter Zijlstra wrote:
>> > On Sat, Oct 24, 2015 at 11:01:02AM -0700, Olav Haugan wrote:
>> > > Task->on_rq has three states:
>> > >   0 - Task is not on runqueue (rq)
>> > >   1 (TASK_ON_RQ_QUEUED) - Task is on rq
>> > >   2 (TASK_ON_RQ_MIGRATING) - Task is on rq but in the process of being
>> > >   migrated to another rq
>> > >
>> > > When a task is moving between rqs task->on_rq state should be
>> > > TASK_ON_RQ_MIGRATING
>> >
>> > Only when not holding both rq locks..
>>
>> IMHO I think we should keep the state of p->on_rq updated with the correct state
>> all the time unless I am incorrect in what p->on_rq represent. The task
>> is moving between rq's and is on the rq so the state should be
>> TASK_ON_RQ_MIGRATING right? I do realize that the code is currently not
>> broken. However, in the future someone might come along and change
>> set_task_cpu() and the code change might rely on an accurate p->on_rq value. It
>> would be good design to keep this value correct.
>
> At the same time; we should also provide lean and fast code. Is it
> better to add assertions about required state than to add superfluous
> code for just in case scenarios.

The state is only worth publishing if it's exceptional.  I think
Peter's new documentation helps to make this more clear.

The intent of this change may be better captured by pointing out in a
comment somewhere that detach_task() is *also* updating the task_cpu
pointer which then lets us lean on holding that lock to make the state
non-interesting.`
> --
> 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/
--
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/