Re: buggy GFP_KERNEL allocators

From: Andrea Arcangeli (andrea@suse.de)
Date: Sat Jan 29 2000 - 08:48:23 EST


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@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:23 EST