buggy GFP_KERNEL allocators

[Andrea Arcangeli]

On Fri, 28 Jan 2000, Andrea Arcangeli wrote:

>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);

That's another place that needs the sched_yield move from the callee to
the caller if you'll want to take my approch to the problem.

--- 2.2.15pre4-raid1/drivers/block/raid1.c.~1~	Tue Dec 22 17:12:38 1998
+++ 2.2.15pre4-raid1/drivers/block/raid1.c	Sat Jan 29 14:45:24 2000
@@ -211,7 +211,11 @@
 	while (!( /* FIXME: now we are rather fault tolerant than nice */
 	r1_bh = kmalloc (sizeof (struct raid1_bh), GFP_KERNEL)
 	) )
+	{
 		printk ("raid1_make_request(#1): out of memory\n");
+		current->policy |= SCHED_YIELD;
+		schedule();
+	}
 	memset (r1_bh, 0, sizeof (struct raid1_bh));
 
 /*

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/