linux/net/ipv4, branch v2.6.27.54

tcp: fix CONFIG_TCP_MD5SIG + CONFIG_PREEMPT timer BUG()

2010-04-01T22:52:19Z

commit 657e9649e745b06675aa5063c84430986cdc3afa upstream. I have recently came across a preemption imbalance detected by: <4>huh, entered ffffffff80644630 with preempt_count 00000102, exited with 00000101? <0>------------[ cut here ]------------ <2>kernel BUG at /usr/src/linux/kernel/timer.c:664! <0>invalid opcode: 0000 [1] PREEMPT SMP with ffffffff80644630 being inet_twdr_hangman(). This appeared after I enabled CONFIG_TCP_MD5SIG and played with it a bit, so I looked at what might have caused it. One thing that struck me as strange is tcp_twsk_destructor(), as it calls tcp_put_md5sig_pool() -- which entails a put_cpu(), causing the detected imbalance. Found on 2.6.23.9, but 2.6.31 is affected as well, as far as I can tell. Signed-off-by: Robert Varga Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

tcp: advertise MSS requested by user

2009-07-02T23:31:54Z

commit f5fff5dc8a7a3f395b0525c02ba92c95d42b7390 upstream. I'm trying to use the TCP_MAXSEG option to setsockopt() to set the MSS for both sides of a bidirectional connection. man tcp says: "If this option is set before connection establishment, it also changes the MSS value announced to the other end in the initial packet." However, the kernel only uses the MTU/route cache to set the advertised MSS. That means if I set the MSS to, say, 500 before calling connect(), I will send at most 500-byte packets, but I will still receive 1500-byte packets in reply. This is a bug, either in the kernel or the documentation. This patch (applies to latest net-2.6) reduces the advertised value to that requested by the user as long as setsockopt() is called before connect() or accept(). This seems like the behavior that one would expect as well as that which is documented. I've tried to make sure that things that depend on the advertised MSS are set correctly. Signed-off-by: Tom Quetchenbach Signed-off-by: David S. Miller Cc: Willy Tarreau Signed-off-by: Greg Kroah-Hartman

tcp: fix >2 iw selection

2009-06-12T03:01:18Z

[ Upstream commit 86bcebafc5e7f5163ccf828792fe694b112ed6fa ] A long-standing feature in tcp_init_metrics() is such that any of its goto reset prevents call to tcp_init_cwnd(). Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

netfilter: {ip, ip6, arp}_tables: fix incorrect loop detection

2009-05-02T17:24:08Z

upstream commit: 1f9352ae2253a97b07b34dcf16ffa3b4ca12c558 Commit e1b4b9f ([NETFILTER]: {ip,ip6,arp}_tables: fix exponential worst-case search for loops) introduced a regression in the loop detection algorithm, causing sporadic incorrectly detected loops. When a chain has already been visited during the check, it is treated as having a standard target containing a RETURN verdict directly at the beginning in order to not check it again. The real target of the first rule is then incorrectly treated as STANDARD target and checked not to contain invalid verdicts. Fix by making sure the rule does actually contain a standard target. Based on patch by Francis Dupont Signed-off-by: Patrick McHardy Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

tcp: Fix length tcp_splice_data_recv passes to skb_splice_bits.

2009-02-17T17:46:25Z

[ Upstream commit 9fa5fdf291c9b58b1cb8b4bb2a0ee57efa21d635 ] tcp_splice_data_recv has two lengths to consider: the len parameter it gets from tcp_read_sock, which specifies the amount of data in the skb, and rd_desc->count, which is the amount of data the splice caller still wants. Currently it passes just the latter to skb_splice_bits, which then splices min(rd_desc->count, skb->len - offset) bytes. Most of the time this is fine, except when the skb contains urgent data. In that case len goes only up to the urgent byte and is less than skb->len - offset. By ignoring len tcp_splice_data_recv may a) splice data tcp_read_sock told it not to, b) return to tcp_read_sock a value > len. Now, tcp_read_sock doesn't handle used > len and leaves the socket in a bad state (both sk_receive_queue and copied_seq are bad at that point) resulting in duplicated data and corruption. Fix by passing min(rd_desc->count, len) to skb_splice_bits. Signed-off-by: Dimitris Michailidis Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

tcp: splice as many packets as possible at once

2009-02-17T17:46:25Z

[ Upstream commit 33966dd0e2f68f26943cd9ee93ec6abbc6547a8e ] As spotted by Willy Tarreau, current splice() from tcp socket to pipe is not optimal. It processes at most one segment per call. This results in low performance and very high overhead due to syscall rate when splicing from interfaces which do not support LRO. Willy provided a patch inside tcp_splice_read(), but a better fix is to let tcp_read_sock() process as many segments as possible, so that tcp_rcv_space_adjust() and tcp_cleanup_rbuf() are called less often. With this change, splice() behaves like tcp_recvmsg(), being able to consume many skbs in one system call. With typical 1460 bytes of payload per frame, that means splice(SPLICE_F_NONBLOCK) can return 16*1460 = 23360 bytes. Signed-off-by: Willy Tarreau Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

udp: increments sk_drops in __udp_queue_rcv_skb()

2009-02-17T17:46:23Z

[ Upstream commit e408b8dcb5ce42243a902205005208e590f28454 ] Commit 93821778def10ec1e69aa3ac10adee975dad4ff3 (udp: Fix rcv socket locking) accidentally removed sk_drops increments for UDP IPV4 sockets. This field can be used to detect incorrect sizing of socket receive buffers. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

udp: Fix UDP short packet false positive

2009-02-17T17:46:23Z

[ Upstream commit 7b5e56f9d635643ad54f2f42e69ad16b80a2cff1 ] The UDP header pointer assignment must happen after calling pskb_may_pull(). As pskb_may_pull() can potentially alter the SKB buffer. This was exposted by running multicast traffic through the NIU driver, as it won't prepull the protocol headers into the linear area on receive. Signed-off-by: Jesper Dangaard Brouer Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ipv4: fix infinite retry loop in IP-Config

2009-02-17T17:46:20Z

[ Upstream commit 9d8dba6c979fa99c96938c869611b9a23b73efa9 ] Signed-off-by: Benjamin Zores Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

tcp: don't mask EOF and socket errors on nonblocking splice receive

2009-01-25T00:36:19Z

[ Upstream commit: 4f7d54f59bc470f0aaa932f747a95232d7ebf8b1 ] Currently, setting SPLICE_F_NONBLOCK on splice from a TCP socket results in masking of EOF (RDHUP) and error conditions on the socket by an -EAGAIN return. Move the NONBLOCK check in tcp_splice_read() to be after the EOF and error checks to fix this. Signed-off-by: Lennert Buytenhek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman