linux-kernel - Re: [PATCH 2/7] sched: Fix picking a task switching on other cpu (__ARCH_WANT_UNLOCKED

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]

Date:	Sun, 21 Sep 2014 00:09:05 +0400
From:	Kirill Tkhai <tkhai@...dex.ru>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Kirill Tkhai <ktkhai@...allels.com>, ralf@...ux-mips.org
Subject: Re: [PATCH 2/7] sched: Fix picking a task switching on other cpu
 (__ARCH_WANT_UNLOCKED_CTXSW)

В Сб, 20/09/2014 в 20:54 +0200, Peter Zijlstra пишет:
> On Sat, Sep 20, 2014 at 08:33:26PM +0200, Peter Zijlstra wrote:
> > On Sat, Sep 20, 2014 at 08:51:22PM +0400, Kirill Tkhai wrote:
> > > From: Kirill Tkhai <ktkhai@...allels.com>
> > > 
> > > We may pick a task which is in context_switch() on other cpu at the moment.
> > > Parallel using of a single stack by two processes is not a good idea.
> > 
> > Please elaborate on who exactly that might happen. Its best to have
> > comprehensive changelogs for issues that fix races.
> 
> FWIW IIRC we can remove UNLOCKED_CTXSW from IA64 and I forgot if I
> audited MIPS, but I suspect we can (and should) remove it there too.
> 
> That would make this exception go away and clean up some of this ugly.

Yeah, you've said me about IA64:

http://www.spinics.net/lists/linux-ia64/msg10229.html

It's about 10 years since the logic, which was documented in ia64
header, has been removed. It looks like, ia64 maintainers are not
interested much...

***

To do not to start a new message. I've found the above when I was
analysing if the optimisation below is OK (assume, we have accessor
cpu_relax__while_on_cpu()):

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7d0d023..8d765ba 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1699,8 +1699,6 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
 		goto stat;
 
 #ifdef CONFIG_SMP
-	cpu_relax__while_on_cpu(p);
-
 	p->sched_contributes_to_load = !!task_contributes_to_load(p);
 	p->state = TASK_WAKING;
 
@@ -1708,6 +1706,9 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
 		p->sched_class->task_waking(p);
 
 	cpu = select_task_rq(p, p->wake_cpu, SD_BALANCE_WAKE, wake_flags);
+
+	cpu_relax__while_on_cpu(p);
+
 	if (task_cpu(p) != cpu) {
 		wake_flags |= WF_MIGRATED;
 		set_task_cpu(p, cpu);

Looks like, now problem here. Task p is dequeued, we can set sched_contributes_to_load and state
here, also task_waking does not produce problems, only arithmetics is there. select_task_rq()
is R/O function.

Now I'm testing this.

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