Messages in this thread | | | Date | Mon, 23 Mar 1998 09:19:23 -0800 | From | "David S. Miller" <> | Subject | Re: bug in 2.1.89 include/net/sock.h? |
| |
From: "A.N.Kuznetsov" <kuznet@ms2.inr.ac.ru> Date: Mon, 23 Mar 1998 20:11:34 +0300 (MSK)
Dave, I slept for 12 hours today, and now my mind is a bit clearer. My advice, have good sleep and the problems will be solved themselves :):)
I agree, I just did the same ;-)))
Now: - we should add to wmem_alloc at least 1 byte per clone. (and Alan will say, and he will be absolutely right, that you must add at least sizeof(struct sk_buff))
And I agree with Alan too ;-)
- your loop in tcp_send_fin will kill host, if sock_wmalloc fails because of problems in device (f.e. excess collisions) Even worse, if it will fail because queue is saturated by tcp send queue, if will block forever, because socket is locked and nobody will able to shrink the queue. Apparently, you wanted to write alloc_skb() there rather than sock_wmalloc.
Yes, this is the case... actually, I set "force" flag in this call to sock_wmalloc() so effect should be the same excelt that skb->sk is set and memory is accounted for. (I have to make for this result anyways, since this SKB will be placed on write_queue, cloned, then the clone transmitted, unlike the ACK case)
SIDE NOTE: ANK is making references to the latest TCP send engine code which will be sent to Linus in a big patch today, so it is not present in the current 2.1.90 sources.
Actually, I have strong feeling, that for tcp wmem_alloc should be split to two parts. One of them is for tcp send queue and driven only by tcp protocol logic, another is for packets, which are in fly.
I agree.
At least, it would solve the conflict between resource limiting and flow control. The idea is not mature, but I feel it is correct. Dave, do not forget also about those poor ppp guys; now device driven flow control does not work for tcp, which can be incorrect in some curcumstances.
Can you remind me, what magic we used to perform in 2.0.x to help these people? ;-)))
Later, David S. Miller davem@dm.cobaltmicro.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |