Messages in this thread | | | From | (Alan Cox) | Subject | Re: select()/socket has problems under 2.2.x. | Date | Sat, 6 Mar 1999 15:12:01 +0000 (GMT) |
| |
> >> - if (skb_peek(&tp->out_of_order_queue) == NULL) { > >> + if (!skb_queue_len(&tp->out_of_order_queue)) { > > > >Trivial micro optimization that is not suitable for a stable kernel patch. > > ??
Indeed. skb_queue_len is if anything going to be faster. In 2.0 skb_queue_len was slow, in 2.2 its not - Andrea is right
> I could agree to go in the slow path but it looks like the right place to > put it according to me. Every time you see that the rcvbuf is empty you > should also check that you are not going to deadlock before reject new > incoming packets.
On a ful receive queue you must still always process the ack and window information then throw the frame. Its as simple as that.
State Ack Window if it fits Data Fin end
> I really can't see how this can open a window for a DoS attack. Really > please can you write an exploit for it? Overrunning the rcvbuf if the > queue is empty it's exactly what I wanted to achieve.
By 64K ?
> What if I'll change the MTU during a transer? I just thought at the way > you are proposing and it simply doesn't look like the right way to fix the > bug to me.
If your MTU is < 3 * the max window you propose to offer you should set the MSS lower in the tcp connection options (TCP MSS blah). This also makes tcp work better as well as solving your deadlock.
Alan
- 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/
| |