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]

Message-ID: <1411244358.3396.8.camel@localhost.localdomain>
Date:	Sun, 21 Sep 2014 00:19:18 +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)

В Вс, 21/09/2014 в 00:09 +0400, Kirill Tkhai пишет:
> В Сб, 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

s/now/no/

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