[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <200901270512.n0R5CLXB019113@darkside.asicdesigners.com>
Date: Mon, 26 Jan 2009 21:12:21 -0800
From: Dimitris Michailidis <dm@...lsio.com>
To: davem@...emloft.net
Cc: netdev@...r.kernel.org
Subject: [PATCH] Fix tcp splice length
commit 6c242233648471868b44ea091d461f2db6a93f10
Author: Dimitris Michailidis <dm@...lsio.com>
Date: Mon Jan 26 20:46:56 2009 -0800
Fix length tcp_splice_data_recv passes to skb_splice_bits.
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 <dm@...lsio.com>
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 0cd71b8..76b148b 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -524,7 +524,8 @@ static int tcp_splice_data_recv(read_descriptor_t *rd_desc, struct sk_buff *skb,
struct tcp_splice_state *tss = rd_desc->arg.data;
int ret;
- ret = skb_splice_bits(skb, offset, tss->pipe, rd_desc->count, tss->flags);
+ ret = skb_splice_bits(skb, offset, tss->pipe, min(rd_desc->count, len),
+ tss->flags);
if (ret > 0)
rd_desc->count -= ret;
return ret;
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists