buggy GFP_KERNEL allocators

[Andrea Arcangeli]

On Wed, 26 Jan 2000 kuznet en ms2.inr.ac.ru wrote:

>Hello!
>
>> +				current->state = TASK_RUNNING;	/* We *must* do this before touching userspace! */
>
>This smells suspiciously. Page fault code should not stuck only because
>task state is not running. It contaradicts all the idea behind wait queues.

Exactly. That was my whole point in one of my past emails.

>Essentially, fault is like signal. It must move task state to running.

Agreed.

I think the real fix for 2.2.15pre is this:

--- 2.2.15pre4/mm/page_alloc.c.~1~	Tue Jan 25 15:40:06 2000
+++ 2.2.15pre4/mm/page_alloc.c	Thu Jan 27 09:51:35 2000
@@ -236,16 +236,6 @@
 	RMQUEUE_TYPE(order, 1);
 	spin_unlock_irqrestore(&page_alloc_lock, flags);
 
-	/*
-	 * If we can schedule, do so, and make sure to yield.
-	 * We may be a real-time process, and if kswapd is
-	 * waiting for us we need to allow it to run a bit.
-	 */
-	if (gfp_mask & __GFP_WAIT) {
-		current->policy |= SCHED_YIELD;
-		schedule();
-	}
-
 nopage:
 	return 0;
 }


Doing such schedule make no sense at all. Each caller should have a fail
path that giveups. If we are oom and we don't giveup ASAP it means we'll
have more chances to cause an oom also for the following allocations.

With the above fix applyed all other patches become useless. In my tree
I'll take this approch.

Andrea


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