buggy GFP_KERNEL allocators

[Andrea Arcangeli]

On Thu, 27 Jan 2000, David S. Miller wrote:

>Actually there is one place which cannot fail, allocation of the
>final FIN frame in TCP.  It may never fail, it will loop until
>it gets the memory.

So just move the sched_yield loop into the caller just like getblk just
does so the problem will become local to TCP.

--- 2.2.15pre4/net/ipv4/tcp_output.c.~1~	Tue Jan 25 15:40:06 2000
+++ 2.2.15pre4/net/ipv4/tcp_output.c	Fri Jan 28 10:27:13 2000
@@ -753,12 +753,16 @@
 		}
 	} else {
 		/* Socket is locked, keep trying until memory is available. */
-		do {
+		for (;;) {
 			skb = sock_wmalloc(sk,
 					   (MAX_HEADER +
 					    sk->prot->max_header),
 					   1, GFP_KERNEL);
-		} while (skb == NULL);
+			if (skb)
+				break;
+			current->policy |= SCHED_YIELD;
+			schedule();
+		}
 
 		/* Reserve space for headers and prepare control bits. */
 		skb_reserve(skb, MAX_HEADER + sk->prot->max_header);

>Andrea, please find another way.

Well, the other way is trivial :)

--- 2.2.15pre4/mm/page_alloc.c.~1~	Tue Jan 25 15:40:06 2000
+++ 2.2.15pre4/mm/page_alloc.c	Fri Jan 28 10:29:15 2000
@@ -242,6 +242,7 @@
 	 * waiting for us we need to allow it to run a bit.
 	 */
 	if (gfp_mask & __GFP_WAIT) {
+		current->state = TASK_RUNNING;
 		current->policy |= SCHED_YIELD;
 		schedule();
 	}


But I'd prefer to get rid of such schedule completly in the MM since it is
going to harm the good citizens.

comments?

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/