| To: | Rik van Riel <riel@xxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: tcp.c::wait_for_tcp_memory() buggy ? |
| From: | Andi Kleen <ak@xxxxxxx> |
| Date: | Sun, 29 Oct 2000 08:11:23 +0100 |
| Cc: | davem@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, netdev <netdev@xxxxxxxxxxx> |
| In-reply-to: | <Pine.LNX.4.21.0010290122050.4224-100000@xxxxxxxxxxxxxxxxxxxxxxxx>; from riel@xxxxxxxxxxxxxxxx on Sun, Oct 29, 2000 at 01:28:38AM -0200 |
| References: | <Pine.LNX.4.21.0010290122050.4224-100000@xxxxxxxxxxxxxxxxxxxxxxxx> |
| Sender: | owner-netdev@xxxxxxxxxxx |
| User-agent: | Mutt/1.2.5i |
On Sun, Oct 29, 2000 at 01:28:38AM -0200, Rik van Riel wrote: > Except for doing a test on tcp_memory_free(sk), where we > do NOT hold the lock we're so dutifully clinging to during > the rest of the loop... And rechecking it later while holding the loop on the next iteration. Also usually the caller also does a check again and iterates as needed. > > As I said, I can't put my finger down on what exactly is > wrong, but this code looks subtle enough that, together > with the bugreport I got (on IRC), I have the feeling that > it just _can't_ be right ... With the right setup of multiple threads writing all the time on a single socket you could probably starve one, making it loop forever here. (it does not try to be fair) -Andi |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | tcp.c::wait_for_tcp_memory() buggy ?, Rik van Riel |
|---|---|
| Next by Date: | Re: [patch] NE2000, Jeff Garzik |
| Previous by Thread: | tcp.c::wait_for_tcp_memory() buggy ?, Rik van Riel |
| Next by Thread: | Re: tcp.c::wait_for_tcp_memory() buggy ?, Ingo Molnar |
| Indexes: | [Date] [Thread] [Top] [All Lists] |