linux-kernel - Re: CFS and suspend2: hang in atomic copy (was: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS])

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0704191117530.8557@frodo.shire>
Date:	Thu, 19 Apr 2007 11:32:03 +0200 (CEST)
From:	Esben Nielsen <nielsen.esben@...glemail.com>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Christian Hesse <mail@...thworm.de>, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Con Kolivas <kernel@...ivas.org>,
	Nick Piggin <npiggin@...e.de>, Mike Galbraith <efault@....de>,
	Arjan van de Ven <arjan@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	suspend2-devel@...ts.suspend2.net
Subject: Re: CFS and suspend2: hang in atomic copy (was: [Announce] [patch]
 Modular Scheduler Core and Completely Fair Scheduler [CFS])



On Wed, 18 Apr 2007, Ingo Molnar wrote:

>
> * Christian Hesse <mail@...thworm.de> wrote:
>
>> Hi Ingo and all,
>>
>> On Friday 13 April 2007, Ingo Molnar wrote:
>>> as usual, any sort of feedback, bugreports, fixes and suggestions are
>>> more than welcome,
>>
>> I just gave CFS a try on my system. From a user's point of view it
>> looks good so far. Thanks for your work.
>
> you are welcome!
>
>> However I found a problem: When trying to suspend a system patched
>> with suspend2 2.2.9.11 it hangs with "doing atomic copy". Pressing the
>> ESC key results in a message that it tries to abort suspend, but then
>> still hangs.
>
> i took a quick look at suspend2 and it makes some use of yield().
> There's a bug in CFS's yield code, i've attached a patch that should fix
> it, does it make any difference to the hang?
>
> 	Ingo
>
> Index: linux/kernel/sched_fair.c
> ===================================================================
> --- linux.orig/kernel/sched_fair.c
> +++ linux/kernel/sched_fair.c
> @@ -264,15 +264,26 @@ static void dequeue_task_fair(struct rq
>
> /*
>  * sched_yield() support is very simple via the rbtree, we just
> - * dequeue and enqueue the task, which causes the task to
> - * roundrobin to the end of the tree:
> + * dequeue the task and move it to the rightmost position, which
> + * causes the task to roundrobin to the end of the tree.
>  */
> static void requeue_task_fair(struct rq *rq, struct task_struct *p)
> {
> 	dequeue_task_fair(rq, p);
> 	p->on_rq = 0;
> -	enqueue_task_fair(rq, p);
> +	/*
> +	 * Temporarily insert at the last position of the tree:
> +	 */
> +	p->fair_key = LLONG_MAX;
> +	__enqueue_task_fair(rq, p);
> 	p->on_rq = 1;
> +
> +	/*
> +	 * Update the key to the real value, so that when all other
> +	 * tasks from before the rightmost position have executed,
> +	 * this task is picked up again:
> +	 */
> +	p->fair_key = rq->fair_clock - p->wait_runtime + p->nice_offset;

I don't think it safe to change the key after inserting the element in the 
tree. You end up with an unsorted tree giving where new entries end up in 
wrong places "randomly".
I think a better approach would be to keep track of the rightmost entry, 
set the key to the rightmost's key +1 and then simply insert it there.

Esben

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