aboutsummaryrefslogtreecommitdiff
path: root/drivers
diff options
context:
space:
mode:
authorKostya B <bkostya@hotmail.com>2008-04-29 22:36:30 -0700
committerDavid S. Miller <davem@davemloft.net>2008-04-29 22:36:30 -0700
commitbe9164e769d57aa10b2bbe15d103edc041b9e7de (patch)
tree35f8c540da31cb8cafa1e6948ae682fd3c8d6bfa /drivers
parent3a8209d19dd791aaac3668be2fa51a9b42113efd (diff)
[IPv4] UFO: prevent generation of chained skb destined to UFO device
Problem: ip_append_data() could wrongly generate a chained skb for devices which support UFO. When sk_write_queue is not empty (e.g. MSG_MORE), __instead__ of appending data into the next nr_frag of the queued skb, a new chained skb is created. I would normally assume UFO device should get data in nr_frags and not in frag_list. Later the udp4_hwcsum_outgoing() resets csum to NONE and skb_gso_segment() has oops. Proposal: 1. Even length is less than mtu, employ ip_ufo_append_data() and append data to the __existed__ skb in the sk_write_queue. 2. ip_ufo_append_data() is fixed due to a wrong manipulation of peek-ing and later enqueue-ing of the same skb. Now, enqueuing is always performed, because on error the further ip_flush_pending_frames() would release the queued skb. Signed-off-by: Kostya B <bkostya@hotmail.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions