Re: bug in 2.1.89 include/net/sock.h?

David S. Miller (davem@dm.cobaltmicro.com)
Mon, 23 Mar 1998 09:19:23 -0800


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